A while ago I decided to remove other races than human from playable characters, but it doesn't make a lot of sense. Also you can only play as male character. But now I have new plans to distribute professions to several humanoid type creatures and also for different genders. The idea is that you can't play let's say a female knight. It's silly and I hate games where gender is simply a choice for "equality" reasons.
Female professions will be exclusive for females and I think they are going to be more difficult if not even iron man (the irony...) style characters.
Well, the actual news is that I've finally started to complete the gameplay features. I have a "plan" for almost everything, but as in case of professions they have to be complete with all features. It's hard work to get that done (and I hate working).
Saturday, 22 November 2014
Thursday, 30 October 2014
Regaining motivation
I took couple of weeks off from programming, partly because I was a bit depressed during the process when I knew I was becoming unemployed. But somehow programming is my "safe place", it makes me enter a state of mind, just like when I'm painting. So it's easy to return even I wouldn't care so much about other aspects of game development.
I have mainly tweaked the source code, trying to improve some technical things. I think it's important to maintain the source code in language level, because it then makes easier to create the actual game content. One thing I've noticed is that I don't use inheritance as much as would be possible. I realized it could be used relatively safely in type classes of game objects. They all share common functionality which could be put into a base class without breaking anything. The problem with inheritance is when it actually requires large scale changes. Then it may be a lot of work for no actual reason other than to improve OOP paradigm which in itself doesn't mean anything in context of game design. No one knows or cares what kind of paradigm was used to create the game.
I have mainly tweaked the source code, trying to improve some technical things. I think it's important to maintain the source code in language level, because it then makes easier to create the actual game content. One thing I've noticed is that I don't use inheritance as much as would be possible. I realized it could be used relatively safely in type classes of game objects. They all share common functionality which could be put into a base class without breaking anything. The problem with inheritance is when it actually requires large scale changes. Then it may be a lot of work for no actual reason other than to improve OOP paradigm which in itself doesn't mean anything in context of game design. No one knows or cares what kind of paradigm was used to create the game.
Friday, 10 October 2014
Mental note
The development of Kaduria has long been reduced to problem areas. There is a list of missing features and bugs, but also source code comments starting with note: as a reminder for later coding sessions. Which may come after a long, long time.
Fixing problem areas is often extremely tedious, but something you have to do. I spend way too much just looking at the problem and trying to think a solution when better approach is simply hack it as fast as possible. Things get worse if you have a mind of a perfectionist. Maybe the biggest philosophical lesson I've gained from roguelike development is trying to let it go and make something working. You can always improve it later when the basic stuff works.
Development is sure going to be "faster" in context of Kaduria now that I'm again unemployed. Maybe something will actually happen, because even I am getting a bit tired of this project.
Fixing problem areas is often extremely tedious, but something you have to do. I spend way too much just looking at the problem and trying to think a solution when better approach is simply hack it as fast as possible. Things get worse if you have a mind of a perfectionist. Maybe the biggest philosophical lesson I've gained from roguelike development is trying to let it go and make something working. You can always improve it later when the basic stuff works.
Development is sure going to be "faster" in context of Kaduria now that I'm again unemployed. Maybe something will actually happen, because even I am getting a bit tired of this project.
Wednesday, 1 October 2014
Procedural degeneration
I've degenerated back to procedural programming! Well, not entirely, but while I was reading stuff about functional programming it made me rethink some things in C++ and OOP. Classes are ok, but sometimes there are clumsy situations where you simply create a class without member variables (data) and use it as "empty" instance, then access functions to do something. It took some time for me to realize that these strange functions are actually... functions. Or "procedures" as in procedural paradigm.
Of course "pure" functions have been always lurking in C++ in form of the standard library (functions like printf etc.). But you can also write your own functions and use them in classes without breaking OOP principles. Functions that are good candidates are generic and algorithmic, they take in simple parameters and return simple values. It's possible to go further than that, but then it starts to be too much like traditional C with all problems it has.
In C++ context it's great to reduce some of burden from classes and also avoid copying source code in member functions when you could use external pure function in all similar places. If those functions are generic enough they can also be reused in other projects really easily, because they don't have any dependencies to the current project. So I've started to create a small function library for Kaduria (rather than creating any game content..) and already removed one of those clumsy empty classes. C++ has the neat feature of closing stuff in a namespace. I've named it "Function" so functions are called as Function::do_something(); which is not only clearly showing that the function library is used, but also protects from name clashes.
I think the function library will stay rather small, because OOP doesn't easily become functional, because member functions work closely with class data and if you try to make it generic function style it probably wont look nice.
Of course "pure" functions have been always lurking in C++ in form of the standard library (functions like printf etc.). But you can also write your own functions and use them in classes without breaking OOP principles. Functions that are good candidates are generic and algorithmic, they take in simple parameters and return simple values. It's possible to go further than that, but then it starts to be too much like traditional C with all problems it has.
In C++ context it's great to reduce some of burden from classes and also avoid copying source code in member functions when you could use external pure function in all similar places. If those functions are generic enough they can also be reused in other projects really easily, because they don't have any dependencies to the current project. So I've started to create a small function library for Kaduria (rather than creating any game content..) and already removed one of those clumsy empty classes. C++ has the neat feature of closing stuff in a namespace. I've named it "Function" so functions are called as Function::do_something(); which is not only clearly showing that the function library is used, but also protects from name clashes.
I think the function library will stay rather small, because OOP doesn't easily become functional, because member functions work closely with class data and if you try to make it generic function style it probably wont look nice.
Friday, 29 August 2014
Redesign of the gameview screen
So I went to doctor and got heavy antibiotics for three weeks plus alpha blocker medicine. It's interesting stuff, supposed to loosen the muscles of pelvic floor, but since I'm special it's affecting to all my muscles, including heart which is of course a muscle. For couple of hours after taking the pill my heart speeds up for quite a bit. It's annoying, but supposedly not very dangerous. However it's working, I'm feeling lot better now.
I've planned the next feature also for some time and now started to implement it. It's the gameview screen (stats, messages, etc. around the gameview) which is going to be modernized to 1.6 aspect ratio. The current resolution is 800x600+ something, but it changed vertically bigger when I added 5 lines of messages. Since displays today are almost all 1.6 ratio it makes sense to change the screen for that size. Even more important it feels like I'm actually planning the screen for the first time, because this far it has only included some of the stats.
The extra space is probably going to have both equipment and inventory as tiles with drag and drop functionality. Yet the UI is kept such that there is no need to use mouse, it's entirely optional and will work at the same time with more traditional keyboard commands.
I've planned the next feature also for some time and now started to implement it. It's the gameview screen (stats, messages, etc. around the gameview) which is going to be modernized to 1.6 aspect ratio. The current resolution is 800x600+ something, but it changed vertically bigger when I added 5 lines of messages. Since displays today are almost all 1.6 ratio it makes sense to change the screen for that size. Even more important it feels like I'm actually planning the screen for the first time, because this far it has only included some of the stats.
The extra space is probably going to have both equipment and inventory as tiles with drag and drop functionality. Yet the UI is kept such that there is no need to use mouse, it's entirely optional and will work at the same time with more traditional keyboard commands.
Saturday, 16 August 2014
Stetson-Harrison project management
I was looking at the oldest files in the project and found two classes (four files) from 2009 that were not used anywhere. It's actually a problem in big projects that you can create multiple ways to do something and then some of that code is never used. These days I try to avoid writing anything for "future use", just as happened for those two classes.
It could be really nice to have an option to somehow mark files in the project different way. You know, when you have the list of files in the project you could mark "ready" files with green color (or something like that) and critical files with red, etc. Neither VC2010 or Code::Blocks has that feature. Some time ago I went to ask C::B developers if they could add that feature, but I got the typical "open source answer" to add it myself. No. You add it, you are the fucking developers of that piece of shit.
I've had problems with my health. Nothing major (I guess), but for couple of days I couldn't concentrate on anything. Sucks. I tried to go to doctor, but he is not in the house for thursdays or fridays. Public healthcare, you know. At monday I'm going to try again. I hate going to doctor, but enough is enough.
I try really hard to concentrate on fixing actual gameplay mechanics rather than fiddle around with source code quality (which is important in a way). When I refactored the map routines it broke stuff elsewhere. Funniest one was walk command (similar to 'g' in Nethack), pretty much everything broke in that routine.
It could be really nice to have an option to somehow mark files in the project different way. You know, when you have the list of files in the project you could mark "ready" files with green color (or something like that) and critical files with red, etc. Neither VC2010 or Code::Blocks has that feature. Some time ago I went to ask C::B developers if they could add that feature, but I got the typical "open source answer" to add it myself. No. You add it, you are the fucking developers of that piece of shit.
I've had problems with my health. Nothing major (I guess), but for couple of days I couldn't concentrate on anything. Sucks. I tried to go to doctor, but he is not in the house for thursdays or fridays. Public healthcare, you know. At monday I'm going to try again. I hate going to doctor, but enough is enough.
I try really hard to concentrate on fixing actual gameplay mechanics rather than fiddle around with source code quality (which is important in a way). When I refactored the map routines it broke stuff elsewhere. Funniest one was walk command (similar to 'g' in Nethack), pretty much everything broke in that routine.
Sunday, 27 July 2014
Clean-up (x2)
The level generation is working again mostly. Some new bugs, but nothing major. Both FOV and light map routines are off for now until I have the energy to concentrate on them. Maybe it's best this way, I can directly see the topology of the level when creating level themes.
There are more important things to do anyway. Next task is mainly go through level themes and add more things, starting from basic topology and then moving on game object distribution. There is a "trick" involved in the process, an idea I had while working on the new version of Teemu. It's of course a secret.
I guess it's these warm days, but I was upset when I noticed that save game routines for each game object type has to be refactored. Most of them were easy to convert, but couple of them needs more work. When I get upset it sometimes makes me clean up places. It's a woman-like way to react, but who cares.
There are more important things to do anyway. Next task is mainly go through level themes and add more things, starting from basic topology and then moving on game object distribution. There is a "trick" involved in the process, an idea I had while working on the new version of Teemu. It's of course a secret.
I guess it's these warm days, but I was upset when I noticed that save game routines for each game object type has to be refactored. Most of them were easy to convert, but couple of them needs more work. When I get upset it sometimes makes me clean up places. It's a woman-like way to react, but who cares.
Subscribe to:
Posts (Atom)