Plan for Thomas "Man of Ice" Lund
by Thomas \"Man of Ice\" Lund · 08/07/2004 (2:12 am) · 2 comments
The excitement is already a solid feeling in my gut. I'll have my first "Game in 2 days" this monday - whohooo.
Some weeks ago the team behind our "Mr. Fumbles Adventures" action adventure game decided that we needed a little fun break from our game dev. And what better to take a small break than organize a little male bonding with beer, bbq and ....... game dev.
My fellow teammates are going to come to my house monday morning and stay for 2 full days and power develop.
We will be "cheating" somewhat - if there is such thing. We have spend some email time deciding what game to make, thrown back and forth some brainstorming ideas and finally decided on an overall game design.
I'll spend some time patching up a TGE with necessary resources so we do not have to wait for compilation at all.
The game
We will attempt to make "King of the Ant Hill" - a god view shooter with several twists.
You control a bug (lady bird, ??? (some middle sized bug) or a dung beetle) in a garden level. Each bug has a weapon strapped on and can shoot with a sand gun (machine gun), green pea gun (middle sized cannon) or dung bombs (heavy mortar). Bugs are controlled with asdw and the weapon turret with the mouse.
Aim of the game is to steal/eat as much food from the various ant storage depots as possible. One depot will become active and the players need to rush to it. Its defended by ant controlled turrets (AI), and there is only room for 1 bug to steal/eat the food. You get points for staying in the depot area over time, and if you die (by ai turrets or player fire) you will be spawned a distance away.
After a while the depot will be empty (random timer) and a new depot is activated. It starts over then with having to rush there etc.etc. Game lasts 15 minutes and the winner is the one who stole most food.
Thats basically it.
We hope to have a playable "prototype" done by day 2 and celebrate with lots of beer and playing the game.
If nothing else, we will take is as a team bonding as well as a learning experience. And the game actually sounds both doable and fun to play, so who knows what will come out of it.
We are a little team of 3. Niels is a 3d modeller, Morten 2d gfx and aspiring TGE scripter and I'll try to get the coding done as well as manage the process. Subversion repository is up and running, wiki is getting heated up (if needed) and beers in the fridge.
Fumbles
Our action adventure game is now entering the final level design and beginning of implementation. I still hope we can get a fully working level 1+2 (out of 5 levels) for IGC, but if not then we have a running (marketing) demo level that we can show too.
I recently went through all scripts and streamlined them a bit, threw out lots of unused code (we started off the starter.fps code) and re-organized stuff. Especially notable is the usage of messaging using my messaging framework. I found a few small annoyances in it which are now fixed, and it works like a charm. I've been able to cleanly separate inter object dependancies by using e.g. an "area manager" and "score manager" that through messaging from triggers make sure there is a "last save point" for spawning the player on death, to manage scores when the player collides with various scorable items (chests, coins). It clearly is a great thing to use messaging, as I have eliminated redundant code, centralized management of game specific functionality that before was distributed into several game objects. E.g. why should the chest object contain code about what kind of content the chest has as well as making sure the player score counters are updated? Now it only contains code for itself and when the chest is opened it sends out a "Player opened me" message. The score manager then gets the event, calculates what the player gained by opening that particular chest and manages the score counters. Very clean and extendable. Plugging in a new type of scorable object is as easy as sending out the same message - thats it.
Messaging
I want to exploit the messaging even further, and have a fairly simple "ai manager" running too. My AI sharks patrolling the waters are plain dumb "follow the path" AI. But when the player enters water, a message is sent out from the player object saying "I entered water". The sharks now pick up that message and if its near them then they enter "search" mode, actively scanning for the player getting too close to them. If they find a player close to them, then they enter "attack" mode and go straight for the player. If the player leaves the water, a message is sent saying "I left water" and all sharks go back to "patrol". If they kill the player in the water they all enter "patrol" too.
The power of messaging is once again displayed, as I can extremely easy dump in various other water AI predators. All they need to do is listen on the "I entered water" message. No messing around with manually turning on/off the "search/attack" mode from the player - and I even save resources due to not having to scan for the player in the water all the time.
FSM
I still havent implemented a FSM yet, which is a bit of a shame. The above example shows a manually coded "primitive state machine" for the sharks, but I bet things would be more clean if I had a "real" FSM in TGE. There is some state machine coded for the weapons in TGE, but I'll have to take a look at that to see if its generally useful for e.g. AI. If not, then I'll probably code a very simple FSM and release it as a resource. As Fumbles grows in size and complexity, I'll for sure need one to control gameplay and gameflow as well as NPC interactions. All these are today manually coded into the scripts which is not good design imho.
Timeframe? No clue - lets see what the summer brings as well as preparations for IGC (I bought my ticket yesterday Thursday!!!!)
Some weeks ago the team behind our "Mr. Fumbles Adventures" action adventure game decided that we needed a little fun break from our game dev. And what better to take a small break than organize a little male bonding with beer, bbq and ....... game dev.
My fellow teammates are going to come to my house monday morning and stay for 2 full days and power develop.
We will be "cheating" somewhat - if there is such thing. We have spend some email time deciding what game to make, thrown back and forth some brainstorming ideas and finally decided on an overall game design.
I'll spend some time patching up a TGE with necessary resources so we do not have to wait for compilation at all.
The game
We will attempt to make "King of the Ant Hill" - a god view shooter with several twists.
You control a bug (lady bird, ??? (some middle sized bug) or a dung beetle) in a garden level. Each bug has a weapon strapped on and can shoot with a sand gun (machine gun), green pea gun (middle sized cannon) or dung bombs (heavy mortar). Bugs are controlled with asdw and the weapon turret with the mouse.
Aim of the game is to steal/eat as much food from the various ant storage depots as possible. One depot will become active and the players need to rush to it. Its defended by ant controlled turrets (AI), and there is only room for 1 bug to steal/eat the food. You get points for staying in the depot area over time, and if you die (by ai turrets or player fire) you will be spawned a distance away.
After a while the depot will be empty (random timer) and a new depot is activated. It starts over then with having to rush there etc.etc. Game lasts 15 minutes and the winner is the one who stole most food.
Thats basically it.
We hope to have a playable "prototype" done by day 2 and celebrate with lots of beer and playing the game.
If nothing else, we will take is as a team bonding as well as a learning experience. And the game actually sounds both doable and fun to play, so who knows what will come out of it.
We are a little team of 3. Niels is a 3d modeller, Morten 2d gfx and aspiring TGE scripter and I'll try to get the coding done as well as manage the process. Subversion repository is up and running, wiki is getting heated up (if needed) and beers in the fridge.
Fumbles
Our action adventure game is now entering the final level design and beginning of implementation. I still hope we can get a fully working level 1+2 (out of 5 levels) for IGC, but if not then we have a running (marketing) demo level that we can show too.
I recently went through all scripts and streamlined them a bit, threw out lots of unused code (we started off the starter.fps code) and re-organized stuff. Especially notable is the usage of messaging using my messaging framework. I found a few small annoyances in it which are now fixed, and it works like a charm. I've been able to cleanly separate inter object dependancies by using e.g. an "area manager" and "score manager" that through messaging from triggers make sure there is a "last save point" for spawning the player on death, to manage scores when the player collides with various scorable items (chests, coins). It clearly is a great thing to use messaging, as I have eliminated redundant code, centralized management of game specific functionality that before was distributed into several game objects. E.g. why should the chest object contain code about what kind of content the chest has as well as making sure the player score counters are updated? Now it only contains code for itself and when the chest is opened it sends out a "Player opened me" message. The score manager then gets the event, calculates what the player gained by opening that particular chest and manages the score counters. Very clean and extendable. Plugging in a new type of scorable object is as easy as sending out the same message - thats it.
Messaging
I want to exploit the messaging even further, and have a fairly simple "ai manager" running too. My AI sharks patrolling the waters are plain dumb "follow the path" AI. But when the player enters water, a message is sent out from the player object saying "I entered water". The sharks now pick up that message and if its near them then they enter "search" mode, actively scanning for the player getting too close to them. If they find a player close to them, then they enter "attack" mode and go straight for the player. If the player leaves the water, a message is sent saying "I left water" and all sharks go back to "patrol". If they kill the player in the water they all enter "patrol" too.
The power of messaging is once again displayed, as I can extremely easy dump in various other water AI predators. All they need to do is listen on the "I entered water" message. No messing around with manually turning on/off the "search/attack" mode from the player - and I even save resources due to not having to scan for the player in the water all the time.
FSM
I still havent implemented a FSM yet, which is a bit of a shame. The above example shows a manually coded "primitive state machine" for the sharks, but I bet things would be more clean if I had a "real" FSM in TGE. There is some state machine coded for the weapons in TGE, but I'll have to take a look at that to see if its generally useful for e.g. AI. If not, then I'll probably code a very simple FSM and release it as a resource. As Fumbles grows in size and complexity, I'll for sure need one to control gameplay and gameflow as well as NPC interactions. All these are today manually coded into the scripts which is not good design imho.
Timeframe? No clue - lets see what the summer brings as well as preparations for IGC (I bought my ticket yesterday Thursday!!!!)
#2
This community is great at thinking outside the box, and this is another great example of that.
08/07/2004 (7:18 am)
I'm looking forward to seeing your demo Thomas. This community is great at thinking outside the box, and this is another great example of that.
Torque 3D Owner Phil Carlisle
But I'd take the decoupling of messages over hardcoded dependancies anyway. I guess in reality, my ideal is to have a mixture of the two.