Windows Some dungeonCrawler game for school

T

TDSrock

Guest
So my current education has tasked me with making a dungeon crawler game. I have been dillgently working on this piece and started codeing it a couple days ago.
I've just now decided to start tracking a dev-log of some kind and showing what I have up to now for the project. Feedback will be much apriciated. Due too time constraints I may not be able to implement everything in this first version, but I'll try to get as much done as I can.

For now two links to documents that I would love to get feedback on.

The game design document:
Some of the stuff there is already outdated/changed and has not been modifyd in that document to reflect the changes...

The type chart
This is the one I'd like the most feedback on.

Both documents should be view only for you guys, if not please do let me know.

Currently working on:
UI elements.
 

Alexx

Member
Yes, the files are view only.

It looks good. I especially like the flowchart, and the document is well formatted and understandable.

I'd bold the titles for your bullet points, to break up the list, other than that a very usable intro.
 
T

TDSrock

Guest
Yes, the files are view only.

It looks good. I especially like the flowchart, and the document is well formatted and understandable.

I'd bold the titles for your bullet points, to break up the list, other than that a very usable intro.
Thanks :)
Embolding lists that have large amount of info is a good idea, will add this to my local version.

It now looks like THIS
 
G

gamedev4life

Guest
tldr: early on in a game's development have less lists and GDD and more game actual dev proper

a lot of ppl will probably disagree w me, but i really think the GDD get too much attention early on. given the nature of game dev--where there is a lot of experimentation, trial and error, creative processes, labor intensive tasks, etc--things change, to put it simply. what you may have thought would work, sometimes doesnt once you implement it and try it out; and the opposite is true too. thus you gotta be open to changing your design plans as your develop your game. this means though that your GDD is a "living document" that is going to change over time, so design a GDD that can be changed easily, and wont take too much time. i know writing a GDD can be fun, but it doesnt really make any thing, its just "talk".

now im not saying dont plan anything--not all!--you gotta plan, but plan in a loose and elemental way, in a way that allows for flexibility and does not suck up a lot of hours. making a game takes many hours to say the least obv, so its not like your gonna dev your game to a point where youre so far down the road where youll come to a point and say "oh no, i didnt plan for "x" in my gdd and time to develop it now! what do i do?!". game dev is such a slow process that planning far ahead isnt necessary imo. my approach is more "lets cross that bridge when we get there"--that is to say "why should i worry about epic combos and weapons if i dont even have a HUD, or the player's animation state machine is kind of clunky". again, this is all in respect to the early part of a game's development.

get the "three C's" down first: camera, controls, character; THEN start fleshing out in more detail the GDD (source: http://www.vice.com/read/why-its-so-hard-to-make-a-video-game).

i mean cmon, you didnt even give us a screen shot lol XD
 
T

TDSrock

Guest
tldr: early on in a game's development have less lists and GDD and more game actual dev proper

a lot of ppl will probably disagree w me, but i really think the GDD get too much attention early on. given the nature of game dev--where there is a lot of experimentation, trial and error, creative processes, labor intensive tasks, etc--things change, to put it simply. what you may have thought would work, sometimes doesnt once you implement it and try it out; and the opposite is true too. thus you gotta be open to changing your design plans as your develop your game. this means though that your GDD is a "living document" that is going to change over time, so design a GDD that can be changed easily, and wont take too much time. i know writing a GDD can be fun, but it doesnt really make any thing, its just "talk".

now im not saying dont plan anything--not all!--you gotta plan, but plan in a loose and elemental way, in a way that allows for flexibility and does not suck up a lot of hours. making a game takes many hours to say the least obv, so its not like your gonna dev your game to a point where youre so far down the road where youll come to a point and say "oh no, i didnt plan for "x" in my gdd and time to develop it now! what do i do?!". game dev is such a slow process that planning far ahead isnt necessary imo. my approach is more "lets cross that bridge when we get there"--that is to say "why should i worry about epic combos and weapons if i dont even have a HUD, or the player's animation state machine is kind of clunky". again, this is all in respect to the early part of a game's development.

get the "three C's" down first: camera, controls, character; THEN start fleshing out in more detail the GDD (source: http://www.vice.com/read/why-its-so-hard-to-make-a-video-game).

i mean cmon, you didnt even give us a screen shot lol XD
I'm agreeing with several points put forward here. Several of these are my own method of operation already. Unfortunately my school disagrees. I'm just trying to give a space for feedback on what is done already and moving forward in this particular project. This is not my frist project, I've completed several in the past, a somewhat mess of an example is the prototype that I provide all the source code for in the topic that my signature links too.
 

Yal

šŸ§ *penguin noises*
GMC Elder
IMO a GDD is much better than early development - it's a lot easier to test out a concept in theory than in practice, and if you work in a team you NEED to have something to make you all have a similar vision about what to make. I mostly do checklists as GDDs for my own use, with occasional doodles, but I feel having to-do lists makes me work a lot more efficiently than when I just sit down in front of my screen and say "let's be creative for one hour".
 
T

TDSrock

Guest
IMO a GDD is much better than early development - it's a lot easier to test out a concept in theory than in practice, and if you work in a team you NEED to have something to make you all have a similar vision about what to make. I mostly do checklists as GDDs for my own use, with occasional doodles, but I feel having to-do lists makes me work a lot more efficiently than when I just sit down in front of my screen and say "let's be creative for one hour".
As much as I'd love to discus the validity of GDD's and how to create/apply them, that is not the purpose of this topic. Much more to document my progress in this particulair project while receiving feedback regarding content and planned content.


In particular I'd love to hear thoughts on the Type chart. It's something I want too mostly feel intuitive, so if anyone has a nice recommendation on it I'd be happy to crunch the numbers to see if I can make it fit.
 
Top