Gamejam Diary – Wed Wk1

No Gravatar

Well, where have we gotten. Chris and I have tightened up the idea for the mechanics, unfortunately there is only so much we can do without a working model as we need to see that the gameplay works before dreaming up shit . I guess this only helps to avoid feature creep 😉

In terms of unity, i’m three quarters through the Lerpz tutorial and ive learnt a lot, apart from some slightly dodgy respawn code. The UI is hell powerful and sadly my lack of scripting knowledge will come back and kick me in the ass.

Days like this I wish I knew PyGame.

This weekend is planned to be a massive work session to get the game to alpha, however a matching color game may morph back into a adventure game. Time will tell… However our inabiliy to make assets would prove to be our downfall in that idea. Hence why we dodged it.

Also the pitch competition shits me off, we don’t have a target to pitch to, I guess this sums up all of Nullabour. Do we go with the sprawling epic of Scott and the Space Elevator, put forward a simple casual game, something innovative using GPS or hell, JellyCat!

God Knows…

Here we go again

No Gravatar

Hey Guys,

We have entered the GameJam! (http://www.gamejam.org) with Lightguard and Garlicbug being the co-conspirators at this stage of the game. We’re supposed to have a game out in Unity within two weeks.

Will we make it? God knows!

ST~

Enemy ideas

No Gravatar

So this is something I sent Jon a while ago, just some ideas for the sewer level enemies. Featured: Lawyer bogman, rat on stilts, shellshock tortoise, mafia hitman spider and sad fat flushed alligator.

Oh yeah, and I have a deviantart thing. Schill. http://pgeronimos.deviantart.com

20080429_scan10002

Some Site Changes

No Gravatar

Hey Guys,

This is mainly for members of Game Pride, I’ve upgraded the website to the latest version of wordpress, fixed the avatars and image uploading and turned on users for the wiki. Therefore if you need to add to the wiki you need to first goto http://www.game.pride.id.au/wiki and then create a user and confirm the email address BEFORE you start writing!

Haven’t fixed the links sidebar, but i’ll get to that.. and the IE bug aswell :p

ST~

Quick “State of Game Pride”

No Gravatar

What’s happening here?

Well, Wraggs, Michael and Myself finished up GET with flying colors, some more flying than others. Mike’s doing honours, Wraggs is finishing up uni and in theory i’m graduating. The final project didn’t come together as planned, engine held us back {but damn, did it look good!}. But now we’re licking our wounds and moving on.

Game Pride has reformed, Sami has moved on and we now have Josh, John and Wraggs joining the team with Paul supporting us from Greece. We need more mans and more movement, but we’re currently working on a 2d platformer in Torque called “JellyCat” which you’ll be seeing more of, and quite a lot of right now.

JellyCat

And on a final note, I’m off to the Game Developers Conference in Feb. I received a scholarship through the IGDA and i’ll be getting into massive debt and possibly a leg up. Look out for more updates through this website on Jellycat and GDC!

ST~

Michael’s Update: Working Scene Graph Implemented

No Gravatar

Ok guys, I’ve successfully implemented a working scene graph and have attached skeletal entities to it to show that it is working, there will need to be a little tiny bit of work to get textures working with the loaded model but no worries we can forget it at this time. The main thing is that we have a working scene graph. I encourage you all to use it!

This means that all the code in Render() in RendererOpenGL is going to be phased out as I attach and implement everything into the scene graph. The only thing that Render() in RendererOpenGL should possess is SceneGraph::Instance()->Render();

That line only, everything else will be handled by the scene graph.

A commit history is available below:

Committing what I’ve done to the trunk
1) Modified AppModel to pave way for the implementation of our working scene graph
2) Implemented a scene graph with MotionNode and GeometryNode fully working.
3) Attached the use of shaders to each entity in GeometryNode with the use of VisualResources which were implemented to help optimise the rendering of individual entites. Currently there exists one VisualResource object which supports the use of skeletals. There will need to be templating done or the creation of more classes to hold different entities. My money is on the templating as it will be easier.
4) Modified Matrix4x4 as it needed additional methods which catered for the rendering of objects in the scene graph if we ever need to use it.
5) Fixed up a few things in RendererOpenGL (going to remove all the hard coded drawn stuff and start using the scene graph to handle all that)
6) Fixed up a couple of things with the shaders and their classes (minimal)
7) Updated the project exec

We now have a working scene graph! USE IT!

Report on Three Day Work Session

No Gravatar

Quick Report, Wraggs and I finished the three day work session on Saturday Morning. I’m just finishing up the last bits and pieces of the documentation but I am pleased to report that we have worked through ALL of the following.

1) Start drawing up state transition diagrams for AI and game states (this will be helpful when we interact our characters with the game engine. what do we need to do and how? new character is in prison, breaks out, finds treasure room, etc….
2) A description of the Game architecture. Basically what was mocked up last semester except this semester there has been quite a few new additions. Skydomes, view frustum culling for entire scenes, CLOD mesh generation, Lua, Gui Interfaces etc. I’d like a detailed description of everything, including what each topic is. By reading the code you’ll be able to know what I’ve done (the comments are enough)
3) Need to have animation. So Chris start getting a wriggle on with those characters. I’m not too fussed about the Cells or anything like that or as a matter of fact, anything to do with animation now that I think about it since we already have it.
4) Gameplay: Ok, we wont be able to get what you guys desired at the end of this project. It will be impossible from my understanding. Instead we’ll go with the simple I’m a hero youre a bad guy, you die etc.
5) Mock up some stuff for NPC AI using the finite state machine. I also want documentation on its states etc (just as above).
6) Game Design Document. Completed (mostly) and reflecting the students workload (A summary workplan of what was set out and what was done. Basically just look back week by week and note what we did each week for every lesson of GET we went to… shaders, lua, fsm, etc)
7) If the above is completed in satisfactory time then we can maybe pursue other avenues which will make you guys more happy.

Oh, Did I mention that we also set milestones and re-engineered the gameplay idea to be a} Simpler and b} a step between basics and the final version. Also the game works fine on higher end computers, we borrowed one to compile and run and it ran fine on the geforce, but my radeon still craps itself.

ST~

Michael’s Update: VIPM mesh generation (FINALLY)

No Gravatar

Yep. Finally! Its been fully completed. I remember some time a few months ago I went and implemented about 80 – 90% of this thing in my game engine only to be hindered by a bunch of run time errors. At that time I had a very good idea on how things should be done but not completely. I decided then to just not worry about it since I already had frustum culled VBO terrain that was loaded from an external file. But knowing me it just wasnt enough. I wanted quad tree formations and I wanted it now!

There really wasnt that many run time bugs to get through, mainly logic problems. That, and I had to create a new class which allowed me to generate my own heightmaps on the fly in my game engine. This is a lot more useful than just loading an external file and using that. Theres the added fun that no matter how many times you load the game now. It’ll always generate a different terrain. Not to mention you can generate three different types of terrain using three different algorithms.

I also went about and fixed up the rendering of objects some more. I still want to get that scene graph finally going but nothing is going to happen until I get some solid work done on my I&J assignment. I’m planning to really get into it this week coming. I’ll try knocking out my part of the design document, then get straight into the design and implementation of the website. And after all thats been set up, just simply work on the coding for the assignment. Should be all good.

And now my log summary of the whole thing:

Outlining changes made to the project…
1) First off. Finally fully implemented VIPM terrain generation in the game engine. Its about fucking time!
2) Modified AppModel to reflect the loading and passing of the new terrain…
3) Modified Vector3 to not include a vector like operation. This was instead moved and is now contained in the Terrain class. It is an embedded terrain specific function call for its own vector struct thats used in the quad mesh.
4) Modified RendererOpenGL to harbour the rendering of the VIPM mesh. Also changed around how things are rendered. (For the better).
5) Modified CurvedSkyplane (minor).
6) Created a new class called HeightmapGenerator which does what its name suggests, that is, creates heightmaps for us from the choice of three different heightmap algorithms. They are: Midpoint, faultline, hill. Does a lot of other cool stuff.
7) Changed Terrain.cpp and .h significantly to harbour these changes. There was also a lot of code that was fixed in order to display the mesh correctly etc.
8 ) Updated stdafx.h to reflect some std::max and min definition problems…
9) Updated vcproj.
10) Updated project exec.

Surprised that it was only that big?

I bet you were. I have a video demo on my skydome stuff but I cant exactly show you what I’m doing until after we get permissions and all that other crap granted.

So I’ll leave the notice here just to notify my team members that theres a video waiting for them if they want to see what I’ve been up to…

Michael

Michael’s Update: Sweet sweet sky domes & Finite State Machines!

No Gravatar

NOTE TO JON: Fix the avatar and personal pic upload problem please!

Hey there, I’ve finally managed to completely implement skydomes into our game engine. It took me a while to finally get rid of all the kinks that were slowing the final product from being finished but now its all working! The visual display is quite good, but theres a bit of re-working to be done on making it look good a long with any scene we wish to use. The hard-coded scene we have now isnt really going to be used if I can do anything about it in the coming weeks. I’ll give you a summary on what I’ve done to finally get it working in the last couple of days:

Outlining the changes made to the project…
1) Modified AppModel considerably to reflect the changes made with SkyDome and how its handled. Also got rid of a lot of misc crap that was unnecessary.
2) Modified WinMain to reflect changes made when shutting down game content.
3) Made some changes to Vector3 in regards to how its public variables are handles and so forth. Also added in a bunch of new methods and operator functions I thought were necessary for future works.
4) Made minute changes to RendererOpenGL.
5) Changed the formatting and handling of if statements in ColourStructs.h
6) Made some considerable changes to SkyDome as necessary to stop the buggyness of the code it was before.
7) Made a minor change with SkyShader and the handling of if functions
8 ) Made a minor change in TGALoader which now allows the user to specify whether or not they want a texture (rather than just the file) flipped when loading content.
9) Updated vertexSkyBox since I thought the use of glDrawRangedElements() was unnecessary and I think I was doing it wrong anyway.
10) Updated the project exec.

NOTE: Sky domes now work in our game engine! This is quite a step forth in the production in our game and the look we’re looking to go for when dealing with out door environments. I for one really wanted this thing working and so spent a lot of time slowly (very slowly) debugging through code and finding every single problem there is with the code and rectifying it.

It took a fair while, but I’ve finally managed to get it done. Hooray!
Yeah, I’m quite pleased with the result although when the stars are generated the do something weird, I’ll figure that out later after I’ve fixed other things.

Onto another cool feature that I’ve managed to successfully implement into the game engine. FINITE STATE MACHINES (FSM)!

Yeah this one was a bit of a bitch to get going but it all worked out nicely. It was also for an assessed workshop we had in our class and so that mostly motivated me to get things done. It took a while and I practically spent an all nighter to get it done since I had to do it my way and my way is the best way (in my opinion =p). Overall it was a success but the logic was shit since I couldnt be bothered making it any better, we just had to demonstrate its usefulness, theres no way I’m going to be spending a lot of time on workshops and so forth overdoing them when all you need to do is just demonstrate the basic principles and get full marks anyway. Thats one thing I learned the hard way last year. Do things, do them right, meet the assessment criteria, don’t do anything more or unnecessary and think you can scab more marks. It doesn’t work that way and you’ll just end up burning yourself out…

Anyway a summary of what I did in order to get the FSM working!

outlining the following changes to the engine…
1) Updated GuiManager, it was linking RendererOpenGL when it clearly didnt need to.
2) Ditto with MainMenu
3) Updated RendererOpenGL.h it had some minor errors.
4) Added the LUA dlls to the project
5) Updated the debug version of the LUA libraries again. It still was giving me build errors, hopefully this one wont!
6) Added two new classes which will be helpful in determining the usefulness of LUA in our game engine (taken from the week 5 workshop)
7) Updated the project exec.

Outlining changes to the project…
1) Updated several classes (formatting was incorrect in some parts and other things….)
2) Still developing a FSM (Finite State Machine) that will incorperate LUA into the game engine. This involves a lot of work and there is still much to be done. There have been an abundant amount of classes created with more to be included soon. After all is done, the FSM should run fine….

Outlining the changes made to the project….
1) Made MASSIVE / EXTENSIVE / INSANE changes to the Project.
Everything now compiles fine without link errors but I have still yet to test the bloody thing! Hopefully it will work! and no run time errors will occur! HERES HOPING!
2) Made changes to several files. Basically changed every LUA file I’d created and then some.
3) Updated the GameTimerHighPerformance class to be the one and only timing instance.
And thats about it! A LOT OF FUCKING CHANGES HAPPENED, NOT TO BE UNDERESTIMATED!

Outlining changes to the project…
1) Modified everything so that there are no problems with the finite state machine, only logic errors….
Works well and suffices for the workshop, when implementing the proper stuff, logic will need to be changed completely.

I wont bother listing the amount of classes I wrote, but overall I wrote around 20 classes and somewhere close to 2700 lines of code to get this thing working.

This marks another step towards my game engine and the usefulness it will offer when we start making our game. I’ll be endeavoring to actually getting the scene graph working as well as fixing up a lot of the rendering problems associated with it. I think that once I’ve successfully implemented the scene graph it will help solve a lot of problems that I’m currently facing and allow for a more robust engine.

I’m also thinking of getting spherical frustum going in order to blot out any other geometry that I’m rendering to the screen since the game is still quite slow on other computers. I’m also going to be spending time on finding out the reason why my game runs so poorly on lower spec computers. There is a tremendous bottleneck somewhere and I’m going to find it out.

I’m also going to switch my view on a lot of things and how aspects of the game are currently handled. I’m going to be switching some of the stuff which can be considered as ‘environment’ variables and change them to singletons if feasible. This is because singletons are useful depending on what you need to do and are better for lower spec machines as they don’t create the need to re-create objects, its not a design that I favour but its useful in games programming.

Heres a screenie of the game so far (NOTE: It looks kinda crappy since I have all the debug stuff going and the floor is black at the moment, real-time viewing is a must since its animated and so forth).

skydome pic