I've been working on "small" stuff like the functionality of menus etc. but now attempting to tackle an important part of the UI design which is the main screen shown when playing the game.
Two usual ways to provide information is either display it all the time or preserve a space for it to display when something happens, or create a command to display some information. I think there are endless possibilities to weigh between easy access to information vs. displaying too much information at once. Also, everything you decide to display will take some space away from the game world area and increase the requirements for pixel resolution of the program.
Up to this day I have had some kind of vague idea how and what to display, but foolishly delayed the complete design in a thought that it will be decided when the RPG system is ready. It's of course nice to know what stats are displayed etc. but it doesn't really have a lot to do with the way you display things.
Sunday, 1 May 2016
Sunday, 17 April 2016
Design as motivation
When bored I'm doing what everyone else is - watching youtube videos. So I was watching this presentation by Scott Meyers (the author of Effective C++ book series) titled 'The Most Important Design Guideline'. I haven't read any of Effective books and I usually don't like these talkative guys, but he did say something interesting that made me realize something.
He is talking about the importance of designing programs to people. He mentions that if the user can't understand easily how to use the program it's not his fault, it's the designers fault. It's kind of obvious reasoning, but actually not that often thought in game design. Roguelikes for sure are notorious for having cryptic user interface solutions.
From that realization I had an idea to approach development from the design point of view. I've never thought of it that way, even I know design is important. But it can be even more, a motivation that drives the development. It's important to have motivation and it can go away when you spend years in developing something. For example Kaduria has practically removed my interest to play games. So finding another source of motivation is nice. It feels nice, that's all I can say.
This new motivation for design has already made a difference in the way I'm programming. I'm now focusing more on important stuff like content which can be seen as design. It also helps me to avoid dwelling in technical details of the source code which is one of my shortcomings in game development.
He is talking about the importance of designing programs to people. He mentions that if the user can't understand easily how to use the program it's not his fault, it's the designers fault. It's kind of obvious reasoning, but actually not that often thought in game design. Roguelikes for sure are notorious for having cryptic user interface solutions.
From that realization I had an idea to approach development from the design point of view. I've never thought of it that way, even I know design is important. But it can be even more, a motivation that drives the development. It's important to have motivation and it can go away when you spend years in developing something. For example Kaduria has practically removed my interest to play games. So finding another source of motivation is nice. It feels nice, that's all I can say.
This new motivation for design has already made a difference in the way I'm programming. I'm now focusing more on important stuff like content which can be seen as design. It also helps me to avoid dwelling in technical details of the source code which is one of my shortcomings in game development.
Saturday, 9 April 2016
Paper and Bag
Last time I was talking about the difficulty of inheriting classes, but after all it was not that hard. Classes Paper and Bag were derived from Item class. Paper contains scroll functionality and Bag is a container item. Both these were previously in Item class, but for most items they were empty data. Moving that data and functionality to derived classes not only makes source code better (less chances for bugs), but saves both memory and save game space.
As I said deriving itself is actually quite easy, because container functionality was already in base class as virtual functions so they work automagically. The problem is in the way items are created and stored in lists. Since C++ doesn't as default support heterogeneous lists you can only put class instances of one type in a list. However this is not such a big problem than I thought, because in this case you can put all items in Item type list and when you need special functionality of Paper or Bag you simply cast Item to Paper or Bag, depending on the object type. It's kind of ugly, but in a way typical C++ solution.
The only real problem is something called object slicing, but it doesn't happen with list of pointers to instances.
Last thing is when you load object data you need to know what the object type is when using heterogeneous lists of objects. I've solved this in theory by using a trick to peek the saved object type (from loaded chunk of data that contains the entire list) before creating the object, since obviously you can't create the object until you know if it's a regular Item, Paper or Bag.
As I said deriving itself is actually quite easy, because container functionality was already in base class as virtual functions so they work automagically. The problem is in the way items are created and stored in lists. Since C++ doesn't as default support heterogeneous lists you can only put class instances of one type in a list. However this is not such a big problem than I thought, because in this case you can put all items in Item type list and when you need special functionality of Paper or Bag you simply cast Item to Paper or Bag, depending on the object type. It's kind of ugly, but in a way typical C++ solution.
The only real problem is something called object slicing, but it doesn't happen with list of pointers to instances.
Last thing is when you load object data you need to know what the object type is when using heterogeneous lists of objects. I've solved this in theory by using a trick to peek the saved object type (from loaded chunk of data that contains the entire list) before creating the object, since obviously you can't create the object until you know if it's a regular Item, Paper or Bag.
Monday, 4 April 2016
That pesky inheritance
I had an idea to test how easy it would be to inherit Paper class from Item class. The slight issue I have with scroll items that only they have a scroll component in Item class which is left empty when the item is not a scroll (or readable item).
Inheriting from Item is easy, but what happens next is not. The problem is that even if you could store Paper type items in a Item list and then cast it to Paper, there are even deeper problems. Perhaps the most difficult one is the way items are saved as a list of items. When you load items, an empty Item class is created and currently there is no way to tell what the next item is going to be. Obviously you would have to create Paper instance for readable items, but to do that you would need to save the type of object, then load if before loading the actual object data.
I don't know how people solve this. Maybe using some kind of obscure pattern trick who knows. Sometimes I'm dreaming of removing inheritance from game objects and creating one gigantic base class for all object types. Then everything could be placed everywhere without the fear of object slicing, you could stuff small monsters into your backpack, carry around a detached door and use it as weapons etc.
Inheriting from Item is easy, but what happens next is not. The problem is that even if you could store Paper type items in a Item list and then cast it to Paper, there are even deeper problems. Perhaps the most difficult one is the way items are saved as a list of items. When you load items, an empty Item class is created and currently there is no way to tell what the next item is going to be. Obviously you would have to create Paper instance for readable items, but to do that you would need to save the type of object, then load if before loading the actual object data.
I don't know how people solve this. Maybe using some kind of obscure pattern trick who knows. Sometimes I'm dreaming of removing inheritance from game objects and creating one gigantic base class for all object types. Then everything could be placed everywhere without the fear of object slicing, you could stuff small monsters into your backpack, carry around a detached door and use it as weapons etc.
Friday, 1 April 2016
Splitting up classes
I have had a tendency to create big classes which are one of problems in this project. Along with SDL2 refactor I've started to split up big classes by removing some features to new classes. Things like automap displaying was previously in Gui class which is kind of thematically correct, because it only contains displaying, but at the same time it's adding up to complexity of the Gui class.
Sometimes creating extra classes can be more work (and code), but it's most likely a better option anyway. Classes can be split up by theme, but in deeper level it becomes easier to split small classes also with inheritance. This is sometimes a natural result of classes becoming small, because you can then either derive from that class or even derive to "upward" direction which means it's possible to create another base class for classes that have same kind of structure.
Being able to create a base class that way is great, because it's making the source code shorter and easier to manage, although in perfect world you should be able to design the class hierarchy before it's refactored this way. I think the way biggest problem with classes are the size and growing number of functions in the class. Yet it's always a trade-off. Big complex classes can do more than small simple classes, but they are much harder to use as classes. A big class can become more like a small program in the program and working with it can be difficult especially when you need to rewrite the code.
I hope the process of elimination becomes easier when I split classes by theme, because that is the way I'm programming this project.
Sometimes creating extra classes can be more work (and code), but it's most likely a better option anyway. Classes can be split up by theme, but in deeper level it becomes easier to split small classes also with inheritance. This is sometimes a natural result of classes becoming small, because you can then either derive from that class or even derive to "upward" direction which means it's possible to create another base class for classes that have same kind of structure.
Being able to create a base class that way is great, because it's making the source code shorter and easier to manage, although in perfect world you should be able to design the class hierarchy before it's refactored this way. I think the way biggest problem with classes are the size and growing number of functions in the class. Yet it's always a trade-off. Big complex classes can do more than small simple classes, but they are much harder to use as classes. A big class can become more like a small program in the program and working with it can be difficult especially when you need to rewrite the code.
I hope the process of elimination becomes easier when I split classes by theme, because that is the way I'm programming this project.
Wednesday, 16 March 2016
SDL2 engine ready
Transition to SDL2 is now done more or less. There are some minor issues with keyboard (scancode confusion) and the way window background was saved and restored in previous version. Shortly described window backgrounds are not saved so the background is trashed. It can be fixed by drawing everything that was in the background.
Other than that I've done some good progress by cleaning up a lot of classes, sort of checking out them again to reduce "things to fix". I'm also starting to get a good idea where the most work should be concentrated which are fine details of level generation and RPG system as a whole.
The RPG system is the biggest problem I have in this project, because well.. it doesn't exist. Or it does in some sort of vague form with some random stats and stuff. But you need lot more than that for a working role-playing system. I did make a big mistake by trying to create it starting from the "wrong end" which means adding lots of stuff without knowing how they play together.
Other than that I've done some good progress by cleaning up a lot of classes, sort of checking out them again to reduce "things to fix". I'm also starting to get a good idea where the most work should be concentrated which are fine details of level generation and RPG system as a whole.
The RPG system is the biggest problem I have in this project, because well.. it doesn't exist. Or it does in some sort of vague form with some random stats and stuff. But you need lot more than that for a working role-playing system. I did make a big mistake by trying to create it starting from the "wrong end" which means adding lots of stuff without knowing how they play together.
Tuesday, 23 February 2016
The great SDL2 adventure part 2
After working for about a week it's not yet over. The core graphics routines are quite ok, but there are lots of external routines calling gui routines that were largely rewritten. I try to keep perfectionist thoughts away and concentrate on replacing 1.2 stuff with 2.0. There are some annoying stuff like data types of SDL mixed with C++ data types of Kaduria. SDL has a rectangle "class" SDL_Rect which is less useful than C++ (OOP) rectangle class of Kaduria. Yet maybe I should have had pixel rectangles as SDL ones in the first place to avoid confusion and conversion routines.
It's quite depressing to remove and rewrite parts of the source code you thought were ok, but that kind of stuff happens when some external library is changed.
It's quite depressing to remove and rewrite parts of the source code you thought were ok, but that kind of stuff happens when some external library is changed.
Subscribe to:
Posts (Atom)