Prop Code
Updated the document from my notes, and a few use cases.
The main break throughs and choices are below
Prop Code
All the prop data will be created from an XML file and parsed into a dictionary which is indexed by Prop Code. All new props must be created from either Cloning or using a Prop Code to create an instance
Unique Tag
This means only one instance of any prop using this tag exist. This solves a lot of problems with upgrade items and tools and such. Not to mention the main building
Timers & Buttons
Possible the biggest break through was the throwing away of a production prop sub class and moving to a timer and button system. Basically when the button is pushed by Frank or the Timer expires a delegate is called which is assigned via data.
Using this system, and the concept of morphing into a new object we can model tree’s growing, ovens and a few other things. The other attraction is Frank can examine objects based on Timers and Buttons. Which lays nicely into some AI reactions I have planned.
The Rest…
Loads of small things I realised and a few things I’ve made note of edge cases and the like. For instance containers ValidInput, and IsFull solves quite a few problems.
I have more to say but I’m going to leave it there.
Cooking Calamity
Use cases, defining more stuff.
Well I suggest following the link for loads of stuff but the biggest thing is cooking. I knew some simple things were core to the game
- Time Based Interactions - Farming
- Activities - Fishing, Fairy, Milling
- Coins & Customisation
- Mini-Games - Race, Egg Hunt, Hide & Seek
Now the one thing that I keep coming back to is the low-level of player interaction. I just need to keep reminding myself that the key element is Frank’s Autonomy. The player can encourage, scold, and highlight. Not to mention choosing how to spend coin and decorate. Ultimately their role is a passive one.
The scope is important as well as it needs to be within reason. The cooking scared me at first till I realised that I could easily just re-use images and use text to describe things. I have a few other ways in mind to drop workload. The final scope will be defined by Friday. I’m also hoping that I will have enough to fully write the xml data format, resources, and skeleton classes.
XML is XtreMLy Tasty Food
So after the coupling issue I’ve been looking at Object Factories and inventories. Now something I learn to love more and more is Data-Driven development. I cannot express my love for it highly enough.
Also thanks to the amazing work of Shawn Hargreaves and all the XNA folks we have automated reflection and xml processing. Which let me tell you is just MAGIC!
The problem I’ve been battling with the last few hours (other than sheer amazement at how awesome the XNA system is) is defining the data structure and whether the class itself should be spat out or a data format, or settings style system is more appropriate.
So the solution as I have come to found a lot recently is use case. Before you build the system, write a scenario, set of rules, or list of items. Then use those to drive the devolpment.
As I often have said to the team on our new project at work, which is on a very tight schedule, make a choice and be definite. It’s okay to be wrong, but imprecise and fluffy is unforgivable.
Coupling and Forethought
Coupling and Forethought
So last night I started looking at setting up the game elements and save data. The moment I started I saw coupling issues rise up like the ugly beast.
Thankfully I’ve seen this monster and I know how to deal with it. I went to bed with pen & paper. This is a problem which is not solved by sitting at an IDE but instead with pen & paper and talking. Too often have I seen projects with terrible coupling or abuse of const and other coding sins.
So after some thought I think I have a structure which holds up under scrutiny.
More notes on Game-Play
More notes on Game-Play
So I’ve been at Uni and running around town so most of my work was in my note-book but it gave me some time to form some thoughts, and define some game-play. Also after much thought a stunning thought came to me. NO VIOLENCE!!!
Player Actions
- Frank
- Pet / Scold
- Feed Frank
- Move Frank
- Highlight Point
- Prop
- Move
- Harvest
- Interact
- Start Game
- Buy Prop
Props
- Bought with Coin
- Upgraded with Coin
- Can be either Exterior or Interior Item
- Production
- Food
- Coin
- Time-Based
- Max Capacity
- Does not Spoil
Buildings
- Bigger on the inside
- Can be upgraded with Coin
Mini-Games
- Practice Mode
- Teach Frank Skills
- Daily Tournament
- Coin can be Won
- Race
- Get from A-B in shortest time
- Hurdles and Path Finding
- Treasure Hunt
- Time Limit
- Find X items in time limit
- Find hidden items for bonus points
- Tag
- Time Limit
- Multiplayer only
- One Pet is it
- The others need to run or hide
- On touch the target becomes it
Frank
- Appearance
- Pattern
- Colour
- Stats
- Speed
- Jump
- Brain
- Skills
Stupid Artist!!
Stupid Artist!!
Oh no wait… that’s me.
As far back as Wednesday last week when I was working my way through this problem I joked about the artist being stupid. This was a sort of anti-joke because I get annoyed when a programmer doesn’t take responsibility for a bug and they multiple re-assign occurs. So much so I’ve developed a blind spot to compensate and assume the artist work is correct.
In my defence it turns out many importers and viewers actually have hacks and fixes in for common artist error. So the hand model looked FINE in the official viewer.
Turns out I had rigged it wrong and as a result the bind poses couldn’t be calculated correctly.
Solution: Re-rig and animate the model
On a side note I’ve lost easily 20+ hours on this single issue.
LD code into the Frank project
Right I’ve moved over most the nice LD code into the Frank project, cleaned up a few things here and there. Made it play nice with the World Manager system.
First thing I did after getting the camera controls in was apply the debug renderer to the stupid animation problem I’m having. Now to clarify both the Worm and Hand have translation and scale applied. In every way other than complexity they are the same.
As you see the hand bones are in the correct place. What you are seeing are the World Transforms which then are multiplied by the Inverse Bind Pose before being based to the shader. So the job is to narrow it down as follows, I’ve eliminated the strike-out words.
- Data
- Art in Max
- Exportor
- Code
- Content Processor
- Setup of Bind Pose & Inverse
Animation of BonesComputation of World Transforms
- Shader
SVN Comments below which sums it up
- SphereHelper.cs is a Spherical Coordinate Helper class
- PolarHelper.cs does the same for Polar Coords
- A DebugRenderer component makes life easier
- New Cameras
- OrbitCamera for 1st & 3rd person Sphere Camera
- TargetCamera for tracking a node from another node
- General clean up in GameplayScreen
- Moved GameplayScreen input helper functions to InputState
- Added Some input helpers to InputState
- Cleaned up Debug Camera controls
So any clues on this animation bug?
Dropping out of the compo
Okay so I’m dropping out of the compo, with 12 hours left to go. I could make a game but the important parts are done and I just got a much needed reminder to get back on track.
So going into this compo the intention was always to focus on XNA, my tech, and pushing my understanding of both forward by doing a quick use case of a game (i.e. LD)
Which I’ve done, things I’ve learnt and coded since Friday night
Things Learnt
- Polar Coordinates are NOT generalised
- Learnt Spherical Coordinate system
- Leant much more about the DX render pipeline
- Learnt about Drawable Components
- Learnt more about generic collections
- Localised Gravity System
- Lots of Maths muscles flexed
Re-useable Code
- Helper Class for Polar Coordinate
- Helper Class for Spherical Coordinate
- Built Orbital Camera based on Spherical Coordinates
- Proper Debug Render Component
So lets get back to Frank. I’m going to ignore the animation problems for now as they are a bit of a brick wall and instead look as some game and behaviour based things. Not to mention plugging the LD code into the Frank Project.
Aaargh Maths!
Aaargh Maths!
After a whole load of confusion between expanded polar coordinates and spherical coordinates which took the better part of the day I’ve managed to generate the map.
On the positive side the Helper classes are re-useable and I’m quite chuffed with the camera stuff. I’m happy with the progress and the most important part
I’m ENJOYING myself!
Okay so the next thing is to build a gravity field to be used as a lookup table. Then to put some characters on there and start blowing stuff up.
Theme: Islands
Theme: Islands
Okay time to make a game in a weekend. At first I wasn’t going to do LD17 but then I realised I could use the engine I’m building for university work. This synergy means the times not wasted, synergy in real life. Besides it will give my lagging progress a much needed oomph.
So I woke up to the theme of islands. My first thought was… Aaaah NO!
Then I started thinking about the cellular automata system I used for the last LD to generate caverns. The system could be adapted from making a single connected cavern to disconnected islands.
Of course I need to use my university engine which is 3D which made me think. Oh I could have islands built of blocks. This is to fit into the graphics pipeline and make them work in 3D. Give them depth so you have floating Ice Berg situation.
This sounded good but then I took the idea further. Polar coordinates with relative gravity. A few stumbling blocks came up with bricks (pun intended). So then I thought go Balls! Then I though how the hell to get a 3D cellular automata, and also that I want hollow planet so to speak.
So then I though polar coordinates means through a bias based on radius using a sine graph or similar. Then wham BAM I got it.