- Category: Uncategorised
- Published on 12 July 2012
- Written by Administrator
- Hits: 5574
Are you a budding game coder somewhere in the UK? Do you despair at the monotony of commercial games and *know* that you could write something better? But are you unsure where to start, which technology to use or how to get the tools to match your talent?
Then this site is for you!
In terms of technology and resources, there has never been a better time to get involved in writing games for your computer, website, tablet or phone - however, with so many options getting started can be daunting prospect. This site is the helping hand you need.
What technology should I use?
Picking the right technology is your first decision and it isn't always easy. Head over to our Tech Selector page to get some advice.
Who are GameDev-UK Coders?
Want to meet *real* people and ask questions in person? GameDev UK Coders meet every month in the Midlands to talk about code, games and game code! Our members include independent games developers, enthusiasts and hobbyists.
- Category: Uncategorised
- Published on 18 July 2012
- Written by Edward
- Hits: 7563
So what technology should I use?
There is a wealth of different technology for games development available at the moment - to include it all would simply be overwhelming. At GameDev-UK.net we're going to focus on just three options (but more may be added if other people want to take on a new section of the site) .
- C# with Unity - Great cross-platform potential, including web deployment, and a relatively friendly development environment, but ties you in to Unity's game engine (obviously!).
- C++ with OpenGL - C++ is all-powerful, but a bit fiendish to get started. OpenGL is still the cross-platform 3D standard of choice. All your code will be your own!
- C++ with Direct X - Same caveats about C++ apply here, but combined with Microsoft's 3D rendering API - which is arguably more powerful than OpenGL, but only supported on Microsoft platforms.
- Category: Projects & Demos
- Published on 02 April 2013
- Written by Edward
- Hits: 4072
I took part in the very friendly Machinis Ludo II Game Jam over the weekend and it was an opportunity to use the stuff I have been working on for GameDev-UK.net. I thought some of you might be interested in the process and outcome. It was certainly a valuable experience for me - I added some new things to the library (primarily physics related game components), modified a few existing components and realised that I probably need to give some of the libraries structure a big re-think.
My game idea was basically an old-school first-person shooter using physical, relatively slow moving, bouncing, projectiles. The emphasis is on careful shots and judging the trajectory of both the 'grenade' and target. It was intended to be a cross between Atari's Battlezone, Quake's grenade launcher and 3D Tanx on the speccy - see my full plan here.
So firstly I used my Visual Studio 2010 game wizard to create the intial project. This worked perfectly but I decided to also add my local copies of the gamelib, G3D and GLS3D projects to the solution as well to make browsing around the primary codebase easier (I'm still learning how bits of G3D work). At this point I SVN'd everything locally so that I could regularly check-in at functional milestones and give myself the ability to roll-back to these if I went 'off on one'. As I'll mention again later, this saved me at least once later in the jam.
The first session of the jam was spent testing the principles of rendering under the control of Bullet physics game components. Particularly valuable was a bullet debug drawer component that allowed Bullet to draw its own collision geometry fairly directly - this enabled me to verify that my own G3D rendered geometry was indeed correctly synchronised with Bullet.
Next I needed to be able to launch my grenade projectiles out into the scene. For this I also needed to write a camera (and launcher) control that had pitch and elevation. I added both an XBox and keyboard 'translator' so either could be used for input, but basically these components came straight out of the existing game lib.
A major technical hurdle I always knew I would have to resolve was how I would 'hook' Bullet's collisions for my own game-specific behaviour. As predicted, this turned out to be tricky mostly because I couldn't (and to some extent still haven't) settled on the "neatest" way to do this within my game component framework. It seemed that the most consistent pattern for my lib is that the game components should receive and handle their own collisions (rather than have an independent collision pair resolver).
I spent several hours setting up an event system where any game component could subscribe to the collision of any other game component (I used boost::Signals2 for this) but this was, of course, only half the problem. As well as *when* an object has collided, I also need to know *what* it has hit! Initially I started making object ID's, but quickly reverted from that and instead created an ICollidable base class interface and I just used dynamic_cast<> to identify the actual object type. Definitely not performance-optimal, but pragmatic and conceptually easy to implement - important when you start to get over-tired and grumpy ;)
So the next step was to turn all these technically interesting bits and bobs into something that could vaguely qualify as a game. I moved the grenade and enemy components under a grenade launcher and enemy manager game component collection class, respectively, and created a std::vector of each. Although not great from a conceptual perspective, the enemy manager turned out to the be the component that had most direct access to most of the game specific states and dependencies - wave number, remaining enemies and score control - so I wired this up to some text renderer components (already in the lib).
Final bit actually involved the most swearing. I just needed to replace the primitive drawable components with model drawables and (and this is the rub) create a couple of simple textured models to load into them. Easy eh?
Previously I have used XSI Mod Tool from Autodesk (formally a modders version of softimage) but I have seen for some time that like XNA this is sadly a dead-end product. In addition, it only exports fbx files. Currently we don't have an importer for fbx but I have got Autodesk's fbx converter, which *should* allow me to convert my models to collada (which I can load through assimp) or obj (which is supported directly inside G3D). Unfortunately, try as I might, Autodesk's fbx converter has failed with *every* model that I have put through it - seriously, it's total bobbins. So, enter my saviour - Blender 2.6! Er... well no, that turned out to be brutal too.
Suffice it to say that I might need to invest some python time in the obj exporter at some point as everything I produced needed hand-editing in Notepad++ before it was actually compliant... So, I simply ran out of time at this point and the 'final' version is still disappointingly wireframe in important areas:
So, obviously lots to do. Most important is that my Bullet collision hook is currently very unreliable and misses a lot of clear collisions. I will definitely work in this. I *may* try and do a bit more on Cannonade. I always intended to create a radar, some physics-based geometric scenery, particle trails on the grenades and, of course, explosions. but I think that whilst it has been a useful learning experience, I'll probably get back onto Buccaneer again for a while...
- Category: DirectX
- Published on 30 January 2013
- Written by Charles Humphrey
- Hits: 10277
So, I have been quite for a long time, life has a habit of getting in the way like that though, I am sure if you are a regular follower of my blog(s), you know I have a tendency to pop in and out.
That said, I am doing a few things, still working on an XNA game (Killer Core) with Mark, have also been participating in an 8WeekGame competition, as well as try and port my existing XNA engine to MonoGame, and I hope this year to, again, be contributing to the fantastic Star Trek fan project ST:Excalibur.
So, where does that leave my C++ stuff, well on the back burner to be honest, but that said, it’s not dead, back in November last year, I mailed someone the source for the engine (warts and all), have not heard if they have found it of much use, but it was nice to know people still have an interest in it. This year my good friend Ed has asked if I would post about what I have done with it so far, and so that’s what I intend to do.
If you are interested in accessing my code directly then let me know I currently have it set up on Assembla.com, so if you are a member, let me know and I can add you and you can get the latest code as it changes.
What am I going to post about then?
Well, I thought I would tell you about the classes I have created in the engine, and explain a little about what they are trying to do. As you probably know, my background for graphics engines is in XNA, so I have tried to create an engine that reflects XNA so it’s easy for me to transition to C++ and DX11, and also means that a lot of the work I have done in my XNA engine I can bring with me to C++.
We have covered the creation of devices and a window in earlier posts, so I am going to skip over that here and just go to the classes. I’ll probably do a post for each class that way I can put a bit more detail into the posts (hope enough for you).