Moving Forwards...

[mdgunn]

I feel unsure about on how we get this game onto more solid ground and move forwards. We seem to lack the core of the game still.  Islands and wizards are not a game, could be things in a book.  What is it that is going to be the game? This still seems to be a problem and why game design is just hard. In a group environment it is particularly hard where things feel less solid.  I think trying to collect together everyone's ideas is VERY difficult to feel a way forward. 

How do people feel we can move forwards? 

1) GAME-JAM APPROACH: Maybe people do own mini-game featuring only 1 or 2 mechanics. Theme would be wizard/magic/tech and floating islands (though I think this is not really a theme but a setting - which is not that useful for ideas in themselves). These are then either fleshed out to their own mini-game or integrated.  May seem tricky but I see the lack of clear game mechanics as a big problem and why a CSG mini-game could be a way around this.   

2) DESIGN DOC APPROACH: We need a more defined design doc which contains some idea of mechanics and why this game would be played.  I'd like to have a stab at the design doc but I think in a democratic group with various loose ideas put forwards it is hard to collect this into a game. I may still try to have a go at the design doc.

3) RIP-OFF APPROACH(in a good way!) :We rip of an existing game.  Not a full game a subset of that EXACT game. This sounds bad but realistically it is probably the easiest way forwards. If we have a clear reference game then we can better know what we are aiming for which seems very difficult at this point. Not the same game but a subset of mechanics from 1 or 2 clearly identified games.  

I think my choices would either be 'Atlas Cube' or 'Ico'. Both are fairly abstract games with simple mechanics and limited play areas. I would ditch ANYTHING from either game that caused extra work beyond a simpler more direct solution and any version would clearly be a small subset of the mechanic of each game and would be developed 1 mechanic at a time.

Other suggestions of how we move forward? 

One problem is I think right now I'm not clear who is active and who is doing what?

 

[mdgunn]

 

I've found a recent game that I think we could practically lift some mechanics out of. 

Mulaka....  

 

I've played a little of this game and personally I found some aspects of the game frustrating and sometimes a little boring but I think it probably gets better and seems to get good marks. I think we could probably pull SOME (and only some) aspects of the following game aspects into our own:

COMBAT - locked in arena is artificial but gives good way to control combat and any craziness LW  navmesh and AI may throw at us. Also may want our magic system to be resource (energy) powered and melee to be the basic method?

QUEST system - a VERY simple dialog system is probably practical to get into the game.

ART - reckon we could probably do the level of environment art here.  Character and enemy probably doable but probably limit would be 1 or 2 simplified enemies (floating - no walk cycles, complex body animations).

CONTROLLER - The game may help us refine a third person controller if wanted to keep in this direction. It would be nice but realistically i just can't see us delivering a polished enough character to make the time saved in just going FP initially (can always do third person mode when we actually HAVE a game).  I suggest we keep TP in mind in any design and test with TP controller as well as FP initially till someone CAN deliver a character we can see working as the TP controller.

 

This isn't necessarily a game I feel I must make (sometimes you feel for a game you want to make yeah?) but it's a game that may be practical make. 

Any thoughts?

[aiaf]

Really like our islands/magic/tech theme.I think all we add should fit the theme even if we ripoff some mechanics.

In some way of another someone did a similar mechanic then we would do , so not against ripoff but keep theme.

 

Hmm lets do a combination of game jam and design document.

 

Create a pool of SMALL SIMPLE mechanics related tasks, anyone can add task as they please.

We know that we need some combat mechanics.

Each person choose and do what mechanic they like.

(examples:

• wizard using fireball
• wizard melee attack
• player approach monolith something happens
• player enter dungeon by portal and need to pick up a certain item
• simple dialog with a rock ).

If someone completes the task and integrates it to the game , it will stay there.

And then we talk and try and fit together all of them.

In mean time we update the design document.

 

 

Another idea maybe something less democratic.

Each of us take turn to be the overlord and make a decision to add a small mechanic, respecting the theme.

After the mechanic is implemented with help from all, the next overlord is appointed that will make another decision. Etc

Could work if we work together and respect the decisions no matter what.

 

Some people might not like this but will cut the need to vote and will move us forward.

And i trust people will make the good calls watching the theme and what was decided in past.

[aiaf]

So not sure either how to move forward, just throwing some ideas.

 

I want to propose we do a voice meeting over discord where we decide things.

 

[mdgunn]

Yeah discord meeting probably necessary.  I prefer text to voice chat but it probably doesn't matter as long as people are there.  I type quick so for me all the typing is not a big deal.

I think you're simple list of tasks (wizard melee etc.) is probably a way to move forward and just get these basic mechanics in place.  I think if we can get some prototype mechanics in place and working together then I think we will be in a better place to commit to some big chunk of work in various areas which we can then split up and work on mostly in isolation without treading on toes too much.

Recently I've struggled to find the time to pull my bits of work together due to some real life issues. I'd like to pull together what I have of combat but if others want to pursue combat mechanics then should be no big deal. 

I will do following post on what as I see as the possible areas for splitting up so we can think about this as we move onward.

 

[mdgunn]

I think I can see something of a way forward now following along from what I was mentioning above.  I think if we split the work into the following major sections we may be able to split work among a few people and move forwards.

We don't need to do all of these things to make a game but I've put the things down that came to mind so we can be aware of them in splitting up work if we want to pursue them.  I think at the minute COMBAT SYSTEM and QUEST SYSTEM  are some main areas which will help take us forwards but I see these as having dependent areas which may need to be done.   For example QUEST SYSTEM suggests possible inventory system. 

Here is one possible way to break things down . Not all bits are the same size: 

1) COMBAT SYSTEM - whatever the person who does it wants to put in place but basically I think we should probably have limited arena areas which get triggered as you enter key areas or do key tasks.  The combat work does not really need to care what the areas are or that there are quests just that the combat area should lock player in (doors indoors or energy shield wall  outdoors).  Player would have to destroy all enemies usually but that may not be the only option. Combat might be best if mostly melee but could be whatever implementer wants. Only about 2  enemy types. Melee plus projectile.  Implementer does not do the enemies, use only stand-in basic geometry or simple shape.

2) QUEST SYSTEM - Simple at first.  Maybe brush trigger based.  Player can trigger completions of entering areas.  Next more complex would probably be player needs item present when entering zone or trying to use it. Develop incrementally. 'Hard code' first 1 or 2 quests if need be.  Do NOT plan and develop fully fledged system.

3) DIALOGUE SYSTEM .  May be tricky to split out as it may need to integrate with quest system. 'Hard code' first 1 or 2 things. DO NOT plan and develop fully fledged system.

4) INVENTORY SYSTEM - KEEP VERY SIMPLE!! Initially do in way which maybe does NOT scale and so have to be flexible, just works for say 3 items with icons showing if holding etc.

5) PLAYER MECHANICS - If we go third person need the character with animations in place.  Personally I think there is enough work that going TP risks the project not completing cause other tasks are incomplete. Still think if we move carefully we can keep the option of TP open for later implementation.  Instead of TP I think there will be enough to concern ourselves with getting together a main player character that integrates with other systems such as combat, quests, possible mini-map, small experience system etc.

6) TERRAIN GENERATION - Base island generation and establishment of different overall biome. Desert, mountain/forest, ice etc.  Aiming for 3 different biomes may seem like too much work but I have done some tests and I think we could have at least mountain/forest and desert/rocky. 
 
7) AREA GENRATION - The is about the construction of individual sub areas upon the terrain. I think we may be able to build sub-areas initially with brushes using the brush kits to get to prototype stage.  Initially can be created outside of terrain using brushes and basic CSG ground rather than terrain. Individual sub areas can be seen as seperate little construction zones which are then placed or rebuilt in the terrain once concept or area is proved.  May need cliffs, rocks, plantes etc which may be specific to biome that can be placed to guide and block routes we don't want user to pursue.

? PROP GENERATION - Low poly prop generation. Individual areas need additional simple assets beyond those required to establish the play area and goals of the area.

9) ENEMY GENERATION - Limited number (2?) of simple enemies organic or hard-surface (quicker?). THis is not concerned with actual combat but model generation and animation and getting into Leadwerks in way that combat scripts can control.

10) CINEMATICS - May be able to minimise this but some simple camera pans and/or cut scenes via camera moving on spline may be an area that could be seperated out. 

11) GAME OPTIONS - Menu systems and control of menu settings effects into game itself.  E.g. global sound level control, music etc. Save/Load/Checkpoint System.

12) Sound FX/MUSIC  - This may be split down or we may leave the finessing of this to someone that finds this area engaging while others drop in simple stand-in assets. Also environmental effects are often forgotten but could be good chunk of work here to setup environment sounds in all locations.

13) Skybox/Sky generation - May fit along side terrain generation work, but may be suitable to just split out. 3 or more skyboxes for our terrains.

I think there will be others but these came to mind first. 

 

[mdgunn]

Overall I think I am happiest doing environments, props and art related stuff  thought I like most of these other things too.  Currently I am mostly spending time refining problems with FBX mesh terrains (I have an annoying issue with larger poly meshes currently) and have also been working on brush kit for outdoor areas.  I always thought the islands would be problematic to integrate (for me anyway) so I'm not that surprised it is taking a while to work through various things.

  

 

[aiaf]

Ill go for quest system, dialog system, inventory system and game options.

I started with dialog system and a way to have game states.

And doing some props in the mean time.