• entries
    16
  • comments
    19
  • views
    16822

Learning something about game development

Sign in to follow this  
omnomnom

1398 views

Very unproductive week for the game but I think I have learned something about game development. I wasted it thinking about the UI. Why? The current UI is a mess. At 800x600 resolution with all the various windows open you can't see the dungeon:

stuff2.png

So I was trying to figure out how to reorder it all. What windows do I need? How do I divide it into different screens with shortcuts? Do I need a hotbar? If the user is in a shop does the floor need to be visible? Should the message log be minimal but expandable? etc. I kept hitting the same brick wall - I can't answer a lot of those questions until I know what game I am making. For example I was wondering how the user would put spells a hotbar, but that depends on, among other things, how many spells there will be. I haven't even worked out the spell system yet (or even decided if I will have spells!)

So I have reached this conclusion: Design the game before making it

Until now I have been trying to make an enginey kind of sandbox and worry about what game I am making later. I know I am making a rogue-like but what is the setting? (medieval? sci-fi? fantasy?). Does it have magic? What is the skill system? What is the XP system? What items will there be? What monsters will there be, etc. How does it all fit together? That's the key part: fitting it together. If I just implement things separately. they won't tie together. I mean that's how minecraft was done and while it's one of the best games ever I think a general weakness of singleplayer is that there was no focused game, just cool bits and pieces being added on in each update. Eg wolves, how do they really fit into the game?

I don't expect to be able to design the game completely up front. There will be discovered problems and new ideas that will modify things, but even with a rough design it will be much easier to prioritize things, faster to develop and the game should be better at the end. I can also bounce the rough design off people who might turn round and say "no way that sounds boring!" and then I can go ahead and do it anyway in defiance. So next post will outline exactly what the game is, the setting, the ending, all of it.

How do other people do all this? Do you already have a 90% complete game design written down?
Sign in to follow this  


4 Comments


Recommended Comments

[quote][b]Design the game before making it[/b][/quote]
Well, this isn't the state of art either :-) Designing before creating would be a waterfall process, whereas the software industry moved over to more agile software processes like [url="http://en.wikipedia.org/wiki/Scrum_%28development%29"]SCRUM [/url](a good read, even for one man projects, there's a lot of good ideas you can benefit from).

In other words, you develop the game with a more or less detailed idea at the start and refine the idea while developing. In this mind, you're developing in an agile way, and believe me, you are not the first one who drop a gui design (I'm currently at the 5th iteration and I fear, that this one is not the last one ).

Experience is one of the most important properties which helps you too avoid such results and you will only learn by failure. In this way, you've done all right , keep the work up :-)

Share this comment


Link to comment
What Ashaman said. There is a lot to be said for rapid prototyping in lieu of a concrete up-front waterfall design done without the experience to make it work. Heck, even with experience, you can waste a lot of time on waterfall design. In my own workflow, my design work is done as much with quick one-off scripts or programs to see something in action as it is with Libre Office open and writing design notes. Any particular component (and this very much holds true for UI) is going to go through several iterations before you get it just right, and there are likely to be quirks and little gotchas that you miss in your big design document that you hadn't anticipated, and that might break the whole design completely. Having a design document will, of course, help with the process; but you need to stay flexible and fast, and don't let the design document herd you into a corner that might be tough to get out of.

Share this comment


Link to comment
I'm pretty much of the same mind as the previous posts. Iterate quickly and in small pieces of the game. At some point you'll have to do a couple of large pieces when you tie various systems together to make sure everything is balanced.

As for your current design, the big problem that I see is that you're running the game under 800x600. Even if you're trying to get that retro feel, there's no reason IMO that you should be using anything less than 1024x768. Doing this should immediately fix your current problem even if you don't change anything else. However, you should also be considering giving the player the ability to change resolutions, which means more testing of the UI to ensure it works decently at various resolutions.

Some specific things about your current UI:

* the message window doesn't need to be that tall by default. Just show one or two lines and give the player the ability to increase the height, even if it's just a button to pop it up to a half-dozen lines high. Give the player the ability to hide the window as well. Hotkeys are your friend! :)

* the window that shows health and other info doesn't appear to need to be as big as it is either, and should be in a corner. Other windows like inventory and such should probably be able to be moved around and overlap each other, just so the player can see more.

* If you haven't already done so, consider coding your UI in an OO manner - have a base "Window" class or some such and several interfaces, such as IResizable, IMoveable, IDropTarget etc. and implement as necessary for each window.

You're doing great so far, just keep it up and don't get discourage. You're working in the toughest genre of game IMO, so consider each little step you complete a victory.

Share this comment


Link to comment
Thanks for all the help everyone, I will do things in an Agile fashion then. I have roughly designed the game plot, etc now, but you are all right I shouldn't go so far as some kind of waterfall model but implement pieces of the game at a time. I guess if I end up implementing a feature I end up removing later that's just part of the testing/learning.

Also thanks about the 1024x768 recommendation. 800x600 people are probably the kind of people who can tolerate cramped screens anyway.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now