• Advertisement
Sign in to follow this  
  • entries
    22
  • comments
    36
  • views
    12807

Entries in this blog

Err yeah. I'm not dead!

The model exporter/loader isn't going to plan as well as I had hoped. I tried to go with an XML based format until I realised that the file sizes I ended up with were horrendous. I've been working instead on a binary chunked format similar to 3DS files, but obviously with an eye to including skeletal animation support.

So I've modified my system to work with binary data as well as XML. To put it into context, the model I am working with is a blender model I downloaded of a T-Rex. As an xml-style file it ended up a staggering 16 megs in size :(. It wasn't hugely optimised, but still!! My binary version of the same file is 955k in size, which is smaller than the original blender file, but at present lacks animation data.

Of course, with all these distractions I haven't even begun work on animation yet. I'm still trying to get uv's to load in correctly... which incidentally weren't working because of shared vertex issues. I'm currently in the middle of a horrid hack to convert from Blenders vertex/uv scheme into my own. I just wish I had a more elegant solution.

All that aside, we went all old school in the office this evening and had a mini Quake III Arena LAN party which was cool :)

Admittedly I've lost a fair amount of skill since "back in the day", but I'm quite happy with how I did... I managed to keep a decent score and I think a fun time was had by all. I really need to practise with the railgun though...

Anyhoo, sorry to anyone reading that may have been hoping got pictures... there are no piccies yet, I'll keep working on the animation stuff and hopefully get there soon.

Cheers,

Steve

*EDIT* Just managed to get it all up and running properly for the first time... so now I have a picture :) It's not too exciting, but now you can see the model in-game for the first time!



*EDIT2* and thanks to my relatively simple rendering system, I've managed to fiddle around and get ambient directional lighting working for the model within only a few minutes :)

New Models :)

Just a quick post to mark the fact that my model export script for blender is now underway and is at the stage where I can export static meshes and see them in the game :)

It's not 100% perfect yet, texture coordinates seem a little off in places, which I think might have something to do with the way D3D uses texture coordinates. Also, objects with no texture in their material do not yet render properly and I also suspect that my exporter might be duplicating some geometry.

But all in all I'm happy so far... I just need to tidy up static mesh exporting/importing and then start to look at exporting blender armatures.

I'll post new screenshots when I get a completely working static mesh, and see if I can post some kind of flash video or something when I have animation up and running, which will probably take a bit longer!

Steve

Okay,

So with the successful refactoring of my rendering engine (up to a point where it will display 2d elements and static 3d models). I'm now going to work on making things look a little less amateur.

First off, I am going to develop and integrate my own XML-like skeletally animated model format. It's one of the things I always wanted to do but never quite got round to. I'm sick and tired of coming across exporter after exporter that either exports models badly or is really awkward to use. I want to just specify a filename, maybe an option or two (but probably not). Hit a button and have a useable model file. Is that too much to ask??!

So yeah, I'm currently working on the parser and integrating it with my renderobjects. As I'm nicking bits of code from my GUI for the parser, I'll also have to have a bit of a rehash of the GUI too, but just enough to get me by.. I wont be adding any amazing new features, just getting something functional working again seeing as I have thrown away the guts of the system in rewriting the parser.

I'm thinking it will take me until about the end of the week to have my XML system fully working and then perhaps another week or two to write the model exporter (in Python for Blender). If it gets done any quicker then it's a bonus.

That all aside, if you didn't spot the comment at the end of my last entry, I managed to raise my frame per second from a horrendous 26 FPS up to a respectable 222 FPS, which is currently rendering around 25 thousand textured polys with alpha blending for the text. That's around about 5.55 million polys per second, give or take a million I guess (these are approximate figures). I don't know if that's good or bad for an ATI X1400, but it's certainly enough to be working with :)

Anyway, back to work for me, I'll update on my skeletal animation endevours as soon as I have anything interesting to say!

Cheers,

Steve

Screenshots :)

Wahaay!! Screenshots at last :)





Okay, yeah, I know, the filtering is rubbish, there is no lighting, the model is bad, blah blah!

The point is that I finally got models rendering again :) I had to refactor my shader constant system again. The template madness proved to be too mad... or should I say just too much maintenance work.

I've replaced it with a more simple system which requires less maintenance, but still works in a similar way. Render methods set up a series of default render states and shader constants, and make requests for any shader constants they have no knowledge of themself.

Render objects can then override states and supply shader constants (such as worl*view*projection matrix). The render method concerned alway has final say over what it receives though. If a render method knows that it's shader cannot handle certain values or states, it can set locks to prevent the overrides. So my 2D render method currently locks the z buffer to disabled for example.

All setting of render states is now neatly done in a single function per object type and is very low maintenance. It is very easy to create new types of renderobject and very easy to change how a given object is rendered. Mission accomplished.

Next thing I have to work on is speeding it up. It's currently only doing 26 frames per second :( I have no batching at the moment and this is a priority, as 26 FPS is just terrible. Mind you, I think I'm doing lots of unnecessary geometry building each frame, which is probably another quick and easy optimisation. I need to start flagging geometry builds only when geometry has been updated.

Then I need to get things looking a little less rough around the edges and hopefully at that point I can start loking at beginning my prototype :)

Cheers,

Steve
Woah... back again, who would have thought :)

Refactoring is now almost complete. I finally have rendering once more. I did have a screenshot, but it's on my home PC and I'm currently at work on my lunch break, but it was boring as it just showed my main menu screen anyway, so no major loss.

But yes, that's right, I now have a UI that is rendering once more. The system worked beautifully when adapted to my bitmap font class and UI classes. I had to make some minor changes to the design once I tried it out in practise, but it all still goes together nice and logically, if not more so since my latest changes.

The main thing that I struggled with was the concept of Shader constants. What object should look after them, where should they be set, etc? The problem is that some constants require changing on a per renderobject type basis, some require changing on a per-renderobject instance basis, some require setting on a per-scene basis and some require setting on a global basis.

So how in the heck can you code something flexible enough to handle all of that without obfuscating game level code with SetShaderConstant function calls which seem out of place?

In the end, I went with some template code madness. The shader constants are now set by default in the render method and the system works by applying overrides. Overrides are only ever set from within a render object, but can be altered through more sensible functions that control them.

So now, I can create a scene:


RenderScene GameScene;




Add some objects to the scene:


GameScene.addObject( Model("test.3ds");
GameScene.addObject( guiControl("window.xml");




Then I can modify a scene shader constant by something like:


GameScene.SetLightDirection( D3DXVECTOR(1,0,0) );




Within the renderobject/scene is where the template madness comes in. In this case, it would be doing something like as follows:


void RenderScene::SetShaderConstantDefault()
{
// Set Light Direction
Shaders::ShaderConstants::LightDirection lightDirection;

// convert the stored light direction into a shader constant
lightDirection.value( lightDirection_ );

shaderConstants_.push_back( lightDirection.proxy() );

}




What happens here is that shaderConstants_ is a vector of shaderConstantProxy pointers. LightDirection is a derived specialized template that operates on D3DXVECTOR4's. The proxy function call returns a proxy object which deconstructs the supplied value into a series of D3DXVECTOR4's (so something like a matrix would automatically be broken down into 4 D3DXVECTOR4's, or a float would be put into a single D3DXVECTOR4). The proxy object allows us to store the templated shader constant type in a vector.

So this allows us to easily set any type of constant (vector, float, matrix, whatever). The code will not compile if we try and set the wrong type of data, e.g. setting a float value for the world matrix, because of the templating, so you really can't mess it up and supply incorrect values. Each derived specialized templated Shader constant (phew, what a a mouthful!) has to override a type function, which returns the type of constant.

Now this means that because we are able to obtain the type of constant at runtime, any given shader can request a constant of a specified type and set it in Direct3D at will. If the object has overridden the constant, the override will be applied. If it does not exist, the default will be set.

This finally means that we can apply any given shader to any given object without messing around with any constants directly. If a given object hasn't overriden a shader constant, the shader just uses a default value (and maybe reports this to a log, so we don't get confused!).

It all sounds complex, but from an end coders perspective, they simply change sensible object specific data (such as the light direction of a scene) and the object completely takes care of setting up all the shader constants for you for both vertex and pixel shaders regardless of what shader type you have applied, be it a 2D GUI shader or a 3D bumpmapping shader.

Now, I usually miss the blindingly obvious easy ways to do what I try and do, so maybe this could have been done in a much more simplistic manner, but assuming not, I think this system is quite nice :)

Cheers,

Steve
Well, two days in a row, lets hope I keep this up :)

Okay, so my refactoring is going well, in fact I have now got back to a stage where I can run my app again and see a cursor... the object rendering isn't completely up and running yet, but the framework is almost all in place.

I have to say that since having started working for a company in the game development business, my learning rate has rocketed. I can say with some certainty now that I'm already a much better coder than I was. I know that I am not perfect, as I've passed the "think I know it all" stage and through into the stage where I'm aware of what I don't know.

But yeah, once upon a time, a refactoring like this would probably have taken me several weeks on and off. This time round I've done the vast majority in a little under 12 hours total. I think this is in no small part due to my current code design method. That being that I now try to approach everything I design from an end user (or end coder) perspective.

If my design for a piece of code requires a load of maintenance every time it is used (register this, initialise that, pass in this, call that function, etc)... the design is usually not good enough in my eyes. I believe that it is usually a matter of simply working out a series of logical abstractions of the classes involved and so I try never to be tempted to name a class something rather undescriptive. If I have done so, then it is a sign that I don't really understand the nature of my design, and I believe it is that which makes the design poor. All this should be aimed at providing the most simple, yet all encompassing interface possible. I suspect that as I progress, I will find that this is made easier by a data driven design (e.g. having material definitions in an external file, etc).

Anyhoo, enough rambling. I know I'm not quite good enough to be preaching yet, so take what I say with a pinch of salt :)

Anyway, design side, it's a little premature possibly, but currently I am struggling to think of a catchy name for my project.

The basic idea I've had is to have a game involving motorbikes. Specifically Motocross Bikes (or whatever you'd call them). Now place said bikes in an urban environment along with riders wielding crazy weapons Road Rash style.

I imagine the idea as being a bit of a cross of Road Rash, Tony Hawk Skating games, Burnout and Motocross Madness.

The twist to the idea is that the game would not strictly be about racing so much as it would be about using the bikes to navigate the urban environment and beat up/shoot down opposing bikers. I just think it would be really cool to ride around jumping on the roof of buildings, flying off ramps, riding up a wall at the peak of a jump to give a boost to a difficult to reach area, performing stunts whilst you're at it and chasing other players around.

You could even forget the weapons at times and have challenges just to reach a certain location and I think it would still be a fun concept.

So that is an introduction to the basic concept and explains why my avatar has now changed to a motorbike and rider icon! I now just have to turn it into a reality and flesh out some more design details (I have a great idea for the control scheme). Once I have my render engine up and running again, I'll be focusing on getting a rapid prototype out.

Anyway, here's looking forward to prototyping screenshots!

Cheers,

Steve

Back!!

So I finally got off my ass and signed up for GDNet+ again. Not like I actually meant to let the subscription lapse, but due to Paypal being something more akin to P.I.T.A.pal, I didn't have much choice.

Anyway, so yeah, this is a good point for me to start back on my journal again. I've finally worked out a game design that has kept me happy for longer than a single week AND I have started work on refactoring all my old and nasty code.

I'm well on the way to having a shiny new rendering engine based on my old code but with a new more logical structure.

I'm a big advocate of trying to structure code in a manner that is as easy to understand as possible. If at all possible, I like to have my code read almost like English.

To that end, the structure of my new render engine is pretty straigthforward, but at the same time, I think it is quite flexible, the structure will be roughly as follows (although this is just a simplistic overview):

Cameras can be rendered.
Cameras contain a view.
A view contains a scene.
A scene contains renderobjects (and is itself a renderobject).
Renderobjects contain Geometry mapped to Materials.
Materials contain a rendermethod.
Materials contain textures.
RenderMethods contain shaders.
RenderMethods contain the code necessary to render an object/scene.
RenderMethods contain RenderParameters.

With this logical structure, it should be really easy for me to just slot in new materials or render methods as desired, so if I usually render a model as follows:

Model model;
model.load("test.3ds");
model.RenderMethod( RenderMethods::Default3DRenderMethod::instance() );

RenderEngine.addObject(model);
RenderEngine.renderAll();

If I later develop a render method to do, say, Bloom Rendering, all I need do is:

model.RenderMethod( RenderMethods::BloomRenderMethod::instance() );

and I can easily test the new rendering style, unlike my current system whichmakes it very difficult to do this!! Also, I could do global changes by simply altering the rendermethod for a given material definition.


Anyway, it's not exactly ground-breaking stuff, but I like the system, it will be much easier to use than my current system, more logical and more flexible, so I think the refactoring is going to be worthwhile. I'll let you know when I have something on screen again :)

I'll be prototyping my new game design once I have stuff on screen again, I'm really looking forward to it and hopefully will post screenies when I get to that point!

Cheers,

Steve

Ugh...

Well, today will have to go down in history as either a) the day I almost worked in the games industry or b) the day I pi$$ed the games industry off (ouch!).

I had been offered the job, but the salary was a little below my expectation. I pushed for a slight increase but failed to get it, so I compromised and accepted the offer. I then took some time to think about it as I knew I was not really happy with a wage cut and loss of benefits such as pension, free Microsoft Certified Professional training and more dependable stability. I decided in the end that I could only compromise if they matched or bettered my salary which unfortunately they could not accomodate. So in short, they withdrew the offer.

I don't bear any grudges against them, after all it is a different role and the experience is quite valuable and the opportunity very rare, however I cannot lower my standards. If I do not command respect over my salary and future at this point in time, then how can I command the respect when it came to future progression and pay review?

So I'll have to simply stick with knowing that I was the first choice for the job. I'm as much at peace with that as I can be. I'll be kicking myself for some time to come but I know it was the right choice. I left it to fate and fate seems to have said that it is not my time... yet.

Hopefully I've not annoyed anyone beyond a future chance in the industry. Hopefuly my time will come. Until then, back to the portfolio, which I'm now determined more than ever to make kick-ass ;)

Cheers,

Steve
The text effect class is now working 100%. I was even that impressed with the results that I created a new improved bitmap font texture and added support for multiple fonts. The scattered random flyin effect looks great... even my step dad who is not very much into games was impressed :)

So, as with all best laid plans, I haven't started work on the scoring system yet. I decided for some reason to look at revamping my particle systems. Probably after watching the Moonpod Insider effects reel and feeling completely outdone! So I've started work on improving my particles. I'm working on transferring the keyframing functionality from my text effects so I can control particle effects via an external text file. I may also look into adding attractors and repulsors, as they do make for some amazing effects :)

The only problem with this is that it has highlighted some slight problems with the organisation of my renderobject class which is used for all renderable objects. I'm now splitting this class into a renderobject class to take care of rendering parameters, transformation, etc and a geometry class to deal with generating the geometry.

I'm working somewhat blind on this at the moment. I haven't rebuilt the project for 3 days because I'm scared of how many errors I'm going to see... although I actually have a feeling it's not going to be that many. The design is in many ways much more intuitive, which has passed onto the coding of the system, it makes sense rather than being a tangled mess of hacks :)

So, anyhoo, I MUST get back to the game coding, so this will definitely be the last thing I do before completing the scoring system. Though I think it will be worth it, some cool particle effects would go down a treat for improving the programmer art, at least if the text effects are anything to go by they will be!

Also, I'm currently looking into a technical support/admin/random jobs job at a games company in Nottingham called Monumental Games. I've had a chat with the CTO of the company, and I'm hopeful, but not banking on getting it. I should hopefully hear back within the next 2 weeks or so. If I did get it though, it would be a dream come true, a step into the doors of the industry and a chance to prove myself. Fingers crossed!

Cheers for reading,

Steve

Making good progress


I now have the first steps of the texteffect class working... and it is even more flexible than I realised... I now have the text rotate around 3 times scaling the height so the text is flattened into a line. The text stops rotating and then grows to full height. This basically gives te text a futuristic feel, a line spins around and then grows into the desired text.

I haven't got individual characters to work yet, but I have written an inherrited texteffect class that should work correctly to give a random direction individual character flyin. I set keyframes so that each character is placed between 2 and 3 screenspace units in a random direction from word screen position. The characters then interpolate back to their original position so each character flys in from a random direction and each character arrives at a different speed.

With a little further work, I might even consider stacking effects, so I could combine a rotation effect with the fly-in effect.

Ideally I'd like to be able to incorporate special shader based effects and particle effects to create a really good text effect system, but I think realistically it's overkill for my simple portfolio project.

Anyhoo, tonights work will be to try to finish the texteffect class and also start (and hopefully finish) the final scoring system.

Cheers,

Steve
The physics is now fully integrated into my engine and works superbly. The slowdown bug I was experiencing was strangely nothing to do with the physics engine. I had a few strange slowdowns when the shuffler reached the edge of the arena and I had guessed that the cause was newton not being great at handling the case where the shuffler traps the puck agains the wall, I assumed it was hitting some kind of recursion limit. The actual cause of the problem was that the application was windowed. As soon as the cursor left the application window and hit an area of the taskbar that displays a tooltip, the aplpication slows to a crawl. I assume this is an issue with the application not having a high enough processing priority, so this will be something to look into shortly. For the time being, running in full screen mode is enough to recitfy the problem and guarantee a consistent 80-100fps.

With the physics out of the way, I'm now looking into completing the game mechanics, with a view to complete the 'fluff' elements once the core gameplay is complete, this will give me a much better idea of a direction for the project giving me time to make core changes without having to drastically rehash the project.

So my next aim is to facilitate the smooth display of bitmapped text so that I can show when a goal has been scored, what the score is, button names and so on. Now this is not a core gameplay mechanic in itself, but without the ability to display the score, there wouldn't be much of a game. Now I already have a working bitmap font class in place, but I want to be able to have the text perform different movement effects such as the text flying onto the screen character by character, or spiralling onto the screen from a distance, zooming in over the course of the animation while rotating. To allow this, I have started work on a texteffect class which is maintained externally to the bitmapfont class. The texteffect class can be passed into the print function to slap the effect onto any given text. So now, if I want to print the score, I make a call to Font->Print() each frame specifying zero duration so the text is overwritten every frame with the updated text. I supply an externally maintained texteffect class which keeps track of what point the animation is up to. For one off pieces of text like a fly-in "Goooooal!!!" piece of text, I can make a one-off call to print and supply it with a set duration and relevant text effect.

The print command stores the texteffect class in the relevant textbox and obtains a matrix to apply translation/rotation/scaling either to the whole string, or to an individual character. The text effect class maintains it's own timer and automatically interpolates rotation/scaling/translation using a standard LERP.

Once I have completed the text effects, I think the next natural step will be to implement the final scoring scheme. Once the scoring scheme is complete I will implement powerups and then I will look at implementing the game flow (start game sequence, game, end game sequence, high score table, movement between levels, etc). Then I will update my rudimentary AI scheme to work in a more professional manner. This should bring me up to a level where I have a complete game that just needs polish, like rollover effects for the UI, a complete set of game options, ironing out bugs, improving the speed and adding fancy graphics effects like shadows, lighting, motion blur and reflection. I may also need to look into allowing the game to run on older graphics cards without pixel shaders. I know there is still a lot of work ahead of me, but I feel like I'm finally getting each component of my game up to a moe professional standard, the bulk of my work has been having to rehash older ideas for components because, although they work well in isolation, they did not fit into the grand design as fluidly as they should.

If I'm lucky, this professional appoach will allow me to reuse or adapt a lot of my existing code in future projects (namely Orbs: Battle Arena).

Speaking of which, I've had a new idea for the Orb game. In order to set it apart from my Airhockey game in terms of complexity, I'm going to throw in elements of another game... Bomberman. A bomberman game using rolling robotic orbs armed with a variety of powerups where players can be destroyed by bombs or forced out of an arena by being either knocked out or blown out, but players respawn to continue play once destroyed albeit at a score penalty. Adding the element of Arena knock-outs should add an extra strategic element to the bomberman genre without making the game too complex. I like the idea because like a move in chess, the move itself is simple, but combined with the ability to drop bombs, the strategic options multiply. I wonder if I can think up any further simple additions that would work in the same vein.

Something for me to think on anyhoo!

Cheers,

Steve

Untitled

I'm really starting to get into using Newton now. I've managed to get Newton working in a basic manner that doesn't have any hiccups any more. It works petty fast and accurately :)

So last night I started work on a wrapper class for Newton and managed to reimplement all the functionality I previously had directly using Newton all in the space of a few hours! The wrapper makes it much more intuitive to use Newton, so altering the physics in future should be a breeze. Had I have understood Newton from the beginning, I would have made the wrapper class immediately.

I've also been thinking about slightly rehashing the particle systems so I have something that integrates better with Newton and works more intuitively in general. I've thought about how to add text effects like spiralling text, fly-in text, expanding text and flashing text. This should allow me to add a bit more polish to my game so it's a bit more impressive as a portfolio piece. Finally, I've also been deciding on a way to improve my powerup system and have decided upon a solution that again will work better than the current system, allowing more flexibility in powerup effects.

Now I like the fact that I have a good roadplan to last me a couple of weeks or so, and by the time I'm done, I should have made good progress towards finishing the game. After that I just need to look into coding the powerups, AI code, finishing the game menu user interface and the high score table.

After that, in theory, it should be time to polish up the code, tighten the graphics (using a playstation controller... duh!) and get it in format ready for use in my portfolio.....must..... finish project..... so .... cloooose!!!
I have now managed to get the Newton Physics SDK working in my Airhockey clone. It has taken quite a lot of hacking around to get the puck and shufflers to act correctly, but now they do, and having integrated Newton, I now have approximately double the framerate, so I'm looking at having framerates of 150-200fps now, which is a nice improvement. It seems documentation is somewhat lacking for Newton... thankfully the documentation is rather complete, but in trying to figure out certain aspects of the engine, I've been left guessing where in the documentation to look... it lacks organisation rather than content. The engine however is working nicely, collisions look and feel better than with my existing code, although there are still slight problems with fast moving objects missing collision, I think I may need to investigate how I'm approaching timesteps.

I'm integrating Newton into my Airhockey game mainly in preparation for my Orbs game. I also figure that it would look good in a portfolio to demonsrate that I can work with code written by other people. I will finish and polish up my Airhockey clone, then as soon as it is complete, jump straight onto working on the Orbs project so I can start building up a portfolio that consists of more than a single project!!

I've had a few changes of heart over the Orbs design though. I'm going to remove a couple of powerups that will be hard to implement in terms of opponent AI. Take the laser grapple for instance, it might sound fun, but coding the AI for it would probably be a project in itself... so I may remove it and save it aside for a later revision of the game, along with several other powerups. On the flip-side, I have a couple of new ideas too which I may reveal in due course ;)

I'm thinking of changing the objective of the game too. The objective will now be to collect Nanobots, falling from the arena or getting damaged will cause you to drop nanobots which can be collected by your opponent. Nanobots will effectively visually and physically represent your score. Perhaps for a campaign mode, you could exchange nanobots like currency for special permanent powerups.

Anyhoo, that's all for this update. I'll see if I can post some pics of my Airhockey clone shortly so you have something to look at, though having said that, my placeholder art really needs replacing as it lacks a consistent style at the moment (i.e. it sucks!!).

Cheers,

Steve

Powerup Design

Thanks to the many helpful people in the game design forum, I now have a complete list of powerups for my game. I've whittled the list down to 20 powerups categorized into groups of 5.

I'm not sure how powerups will work yet; if they will be collected in-game or purchased between games, but I should hopefully be able to adapt the ideas to fit whatever system I eventually decide on.

So without further ado, here is the list:

Defense - 5
Mirror Attack - All projectile/melee attacks are reflected back toward the offending player. Melee attacks cause instant damage on the aggressor, ranged attacks are literally reflected back.
Holo field - Causes 2 ghostly occasionally flickering versions of your Orb to appear and follow you around in order to confuse an attacker.
Phase Shift - This powerup allows you to avoid all attacks for a set period of time, but you cannot use other powerups whilst this one is active.
Bumper - This powerup turns your orb into a bumper... any players orb that comes into contact with you will be sent bouncing in the opposite direction at high speed.
EMP - Disables all active powerups of all players

Offence - 5
Ram - Orb splits into two halves, front half shoots forwards and can be used as a method of ramming the opponent.
Self Destruct - Orb flashes 3 times during a 3 second countdown. Orb explodes at end of countdown dealing major damage within a large radius. Can be aborted part way through if desired.
Blast Mine - Orb can drop a limited number of mines which have a 3 second proximity delay and cause knockback/damage.
Spikes - Give the player more grip and cause damage on contact with opponent.
Gyro-mounted Lasers - Allow the player a limited number of laser shots to damage opponent. No knockback.

Movement - 5
Teleport (or Quantum Improbability Drive :)) - Allows the player to teleport to a position indicated by the mouse cursor.
Jet Pack - Allows the player to cross gaps in the arena and perform a drop down smash attack.
Inertial dampeners - Allows the player to instantly bring the Orb to a state of rest, regardless of current momentum.
Speed Boost - Boosts the speed of the Orb.
Grappling laser - Allows the user to cling onto objects to avoid falling, also allows players to cross difficult parts of the arena more easily. Can grab onto opponents to get them to effectively tow you along!

Physically Altering - 5
Body Swap - You and a random opponent immediately switch physical locations.
Grow - You become larger.
Shrink - You become smaller.
Invisibility - You disappear from view for 10 seconds, or until your first collision with another player.
Electromagnet - Nanobots within a set radius are attracted to you automatically.


Cheers,

Steve

Orbs: Battle Arena

Well, it's been quite some time since I last made a post, but that is mainly due to the fact that I've been trying to come up with a killer design for a portfolio game that:

a) I will enjoy working on
b) is within my technical abilities
c) requires art assets that are within my ability to create
d) I will still enjoy working on once I've been working on it alone for 6 months+

I think I have found that idea now. It is simple, shouldn't take long to make, it is reasonably original, will be great fun to play and will not require immense amounts of artistic content. The idea is to create a Super Monkeyball style deathmatch game which I think I will call Orbs: Battle Arena.

Now I wont go into too much detail, as I am working on a design document at this moment in time (and have no desire to type the contents out twice!!) so I shall post my design document when it is ready so everyone can get a better idea of the design of the game. I have however completed a rough unordered list of the different stages this project will probably entail, which I shall try and update with each new journal entry to show my progress.

My bite-sized tasks are as follows:

+ Load up a 3DS file to use as a static level.
+ Integrate ODE physics for the level and the sphere, get it working with a simple sphere dropped
onto the level, and progress from there
+ Add controls systems and ability to jump/double jump, along with appropriate ODE physics
integration
+ Add code for collectible health
+ Add code for collectible powerups
+ Code powerup effects
+ Add AI opponent(s) [task will probably need breaking down further]
+ Add scoring system
+ Add high score table
+ Add game modes
+ Add game menu system
+ Add moving level components
+ Add scoring system
+ Add High Score table
+ Add sound code
+ Investigate multiplayer possibilities

Anyhoo, I shall keep you all updated, and hopefully post reasonably regular screenshots to keep things interesting!

Any suggestions of a better name for the game would be appreciated, Orbs: Battle Arena is just a working title for the time being!

Cheers,

Steve

It lives!!!

[Please excuse the language in the screenshot... if you are easily offended, don't look!! I had to include it though because it just makes the madlib :)]

Well... it's very very early days, I haven't got every single thing in the program functioning 100%, but I do however have enough functioning to produce complete madlibs!!

Behold my first ever completed madlib and bask in it's comedic glory... or something!

Actually I'm very happy with how it turned out and I think it just goes to show how much of a blast it will be as a game element.... just try reading from the following screenshot without laughing!



Cheers,

Steve

MFC Madness

Well... I wont go into as much detail as I had hoped to, but the post below is really just a list for my own benefit of things left to do on my project. I'm sure as always I'll think of loads more to do.

Anyhoo, I've started work on an MFC based editor for the madlib portion of the game. The neat thing is that the editor can also be used to simply play madlibs, so I can see the system in action before implementing it into the game, and it should just port straight across into my main project with about 10 minutes work.

There is another reason for this move too. I've spotted a ~GBP30,000 a year job that involves MFC, Win32 and STL. Now, I think I may be shooting way above my league, but I can actually say that I am definitely experienced with all the requirement for the job... so I've put in my application and we'll just see if it impresses or not! The reason for the project of course is that it fits in with my current portfolio project, but will also serve as a prime example of my skills in the aforementioned areas... perfect timing!

Anyways, I'll post a link to the MFC project when it's done :)

Steve

To be continued....

(I'll explain this later, lunchbreak almost over!!)

TODO:

- Player only collision objects to stop player from moving inside their goal? (or maybe we allow full freedom of movement instead?)

- Set a collision object at 1 puck radius distance behind the goal mouth that upon collision resets the puck and shuffler positions and adds onto the appropriate players score

- Add bitmapped fonts to display score/player name and current madlib word

- Add particle spark effects when puck hits wall

- Add randomly placed pickups within specified rectangular region that appear at a specified minimum distance away fro the player plus a random amount (ensuring that pickups don't spawn underneath a player!)

- Add collision flash when objects are hit by weapon fire

- Fix sounds to play more reliably (possibly caching multiple copies of a sound for when it needs playing in quick succession which DirectShow seems to suck at)

- Work on A.I. system - add goals, player stats affecting AI style/difficulty, etc

- Add menu system

- Add varying game modes

- Fix physics hiccups if possible

- Create more interesting arenas/pucks/shufflers

- Fix the camera positioning and make mouse movement relative to the view rather than relative to the world axis

Ramblings :)

Well... so okay I didn't get to post at lunch today what with having to work out what to buy for my housemates 30th which, like me, was left until the last minute (too engrossed in coding as usual), I think I brought some really nice thoughtful gifts though, so I don't feel too bad about it ;)

Anyhoo, that aside, I've decided on a couple of modifications to the game, as usual I cannot settle on an idea for longer than 5 minutes!

So I've done the usual thing of running through all the in-game scenarios in my head, and have decided that the powerup thing is slightly out of place as the pace of the game will be so fast that you wont exactly have time to coordinate any effort into getting the word you desire into play. So I needed to think of a way to take the intensity out of the idea. I think the intensity comes from the opponent having direct control over the word you potentially end up with. So I figure that instead, I'll only have the pickups affect the word you are battling to use, that way, once you get a word you like, you don't have to worry too much about the opponent messing up your plans and can concentrate solely on scoring.

Of course the odd rare pickup might do something fiendish such as swap words with your opponent, just to spice it up a little ;) I think I'd also like a good excuse to get some nice particle effects in there... the game lacks anything really nice in the visuals department so far and a few sparks when the puck collides with a wall would go a long way to making it look a little nicer. I can then also use the particle system to create energy bolts and various other effects which I may implement through pickups.

I figure I might even go so far as to allow the ability to defeat your opponent by other means (i.e. shooting them), but I'm not sure if this is overkill.... I should really avoid feature creep and if the concept gets too wierd it may alienate players... gawd knows it's different enough as it is!

Anyhoo, I'm starting work on the madlib system tomorrow or Friday (I've done the class protoype this evening), I'll see how it pans uot, how it plays in reality, I'll draw text using D3DXFont for the time being as it keeps things easy, and then I may update it sometime in the future to use a nice bitmapped font, I do find that plain coloured text does look somewhat dull in a game, so I'm pretty much convinced that bitmapped fonts are the way to go, though I will probably keep it simple as I really don't think it'll be worth delving into spacing issues and suchlike (a lot of work without much impact for a game of this scale I think).

Anyhoo, thanks for reading my ramblings if you have... perhaps soon I'll post some pictures too as I know a journal lacking in pictures is never quite as interesting a read.

Cheers,

Steve

Untitled

Well, just a quick entry as I'm off to work in a sec (hence the turtle icon!).

Last night I quickly changed the skins for the player shuffler, enemy shuffler and puck so they finally look different... I could play with them all looking the same but it sure as heck confused my girlfriend... so I thought I'd take the professional attitude and get it sorted straight away (too often I will leave things like this until the last minute!).

I haven't done anything on the AI yet as I also had to fit in a driving lesson.

I have however, spent the day working out hwo to incoroporate the madness of madlibs and I think I've got it :)

each level (or perhaps set of levels) will have a dictionary of words, players will also be asked to enter their name which will be used in the selection of words available for the level.

Each bout will be a fight over who gets to put the next word into the madlib, as such, the computer will randomly select a word and display it to both players. The players will be able to collect a pickup that moves to the next or previous word, a powerup that enables a weapon which can be used to destroy other pickups and possibly a few other pickups for variety (such as split ball, super speed, etc). The game will then be a battle of trying to collect pickups to get the word to change to the one you desire to fill the madlib, and destroynig with weapons the pickups that might be advantageous to the enemy getting their choice of word into the madlib. Upon scoring the word is set for that mad-lib slot and is attributed to the scorer, with the highest scorer winning!

So yeah, I think I'm a bit happier with that, though perhaps there should be a little more bonus for scoring. Anyhoo, I'd best dash to work and I'll keep working on it. I'll also try and post later today on my lunch break when I'm not in such a rush!

Cheers,

Steve

First Post!

Hey all,

First time using the journal system as I've only just upgraded to GDNet+ which to be fair is somewhat overdue as I've only been a member now for... oooh 5+ years!!

Anyhoo, I feel like I'm giving a little back to the community now, not just with my GDNet+ susbscription, but also I'm being more active in trying to help in the forums now as I'm starting now to feel like I have somewhat of a reasonable grasp of games programming in general... and boy it's taken a long time to get to this stage purely because there is always something new to learn... I suspect it is one of those things you can never truly master.

Anyways, I'm currently working on my physics system for Madlib mayhem. It's pretty much doing the job it should be, but I just found out that it's only really working properly when the collision plane normal's y component is 0, i.e. it is not slanted up or downwards. That's okay though because it will be simple to create a set of collision polygons for any object that follow this rule and is quite in keeping with the 2d/3d style of play.

I also got sick of seeing the enemy puck sitting there doing nothing, so in about 30 minutes I coded up a rudimentary AI system for the puck, and while it sometimes moves about like a kangaroo on speed, it is actually quite a fearsome opponent!

I plan to overhaul this with a more OOP friendly design rather than the hack I presently have in, and I think I'll be more systematic in my design, letting the AI set itself goals such as defending the goal, anticipating the puck position, trying to take a sneaky snipe shot at the goal and so on. I'm going to try and model it as closely as possible on human behaviour and give it a few variables that I can use to adjust the skill such as goal changing speed, offensiveness, defensiveness, etc.

One thing I worry about though is that it may be hard to cater for airhockey tables that are not a regular shape. I'd like to be able to have tables with multiple goals per player, circular tables, triangular tables and so on.... something a bit different to the norm!

I'm also a little unsure how to implement the mad-lib element in a manner that doesn't feel like the idea was just an afterthought. I'm thinking that each round will be a fight over control of the current word going into the madlib. Each map will have a dictionary of words to choose from and players will choose a random word of that category to use. Whoever scores next will have their word inserted into the madlib.

I think this system would be fun, but does feel somewhat tacked on as the word really has no relation to the airhockey gameplay. I have no solution yet, but I'm thinking on it!!

Cheers,

Steve
Sign in to follow this  
  • Advertisement