So I was looking at possibility to move development of Brick Atelier to OSX, just for fun and maybe preparing for future releases on OSX platform. First block on the road was that I can't download XCode, the native IDE for OSX. You can get it from App Store, but when downloading App Store wants to know my billing information. I don't want to give it. Besides, I don't have a credit card which presumably is required in App Store. Yes, it's possible not to have it in some parts of the world.
Code::Blocks can be installed on OSX and it was a success. But then a disaster struck. SDL (a graphics library used in Brick Atelier) can be only used as a framework in XCode. In Code::Blocks you have to use so called unix installation, which I call shit installation. Since OSX doesn't have .dll files as Windows the user has to install SDL if using dynamic linking, because you (again presumably) need library files for SDL. If using static linking you have to release the source code of your project, because SDL 1.2 is LGPL.
OSX is taking worst from the both worlds. On other side there is App Store and Apple's development tools (and if you release on App Store having to join in the development program which costs 99 dollars a year). Then there is unix and open source problems with "good old" GPL. What the fuck is wrong with just writing programs and releasing them the way I want? It looks like I'm not going to write any programs to Mac any time soon.
Isn't it ironic that Windows is the best platform for developer? It doesn't force any suckage from open source ideology or try to force commercial releasing routes. You can do anything you want. You can release the source code if you like, you can use other licenses than GPL, you can sell your soul to Steam if you want etc.
People often ask why don't you join Linux happy open source family. I think it's restricting your options and open source releases are dangerous, because anyone can steal your project and create derivatives of it. GPL is the biggest reason why Linux will never appeal to developers who may want to change their mind and try to get some money from the hard work if or when their project starts to have a commercial potential. GPL and open source ideology would probably work in a communist Star Trek utopia where no one has money.
Developers are extremely important to any OS. What happened to Windows with version 8 was hopefully a good wake up call for Microsoft. If they make the OS like shit the developers are going to run away fast. Then again no one liked 8 and that's why Microsoft is trying to get it right with 10.
Sunday, 14 December 2014
Monday, 1 December 2014
RPG system troubles
I realized that Teemu has the same problem as Kaduria which is the RPG system. Right when I started to create more sophisticated system for Teemu the new version has been in unfinished state for.. a long time. Of course it's not the only thing in todo list, but it's the biggest problem.
Creating a balanced RPG system is not that easy. I guess that's why many games use D&D or some kind of version of it. And worse yet, when you start to create a system you end up something with hit points, stats and stuff. How else it could be done? Maybe I need to think harder to make something different.
Creating a balanced RPG system is not that easy. I guess that's why many games use D&D or some kind of version of it. And worse yet, when you start to create a system you end up something with hit points, stats and stuff. How else it could be done? Maybe I need to think harder to make something different.
Saturday, 15 November 2014
D language
I've studied D language. It's a kind of evolution from C++ as it says. The syntax is familiar to C++ programmer, but there are differences, some of them quite confusing (class vs. struct, immutable vs. const).
With long experience from programming I can clearly see where D is coming from. It's funny, but in a way D is a result of "bad" features of C and C++, yet I think it's wrong to focus only on those bad features. C++ is just doing things that way. Even C++ developers are breaking in constant pressure to become a "modern" language. Well, I guess those new features can't hurt.
Some features in D are nice as you would expect while others are less useful. For example assert seems to be a strong feature in D, but something I would never use myself. Not in C++ or D. Unit testing is also a waste of time in my opinion. D even has a unittest scope for that purpose. What I found nice is that D has built-in array slicing and easy to use string operations. D doesn't have header files which is one of the ancient structures in C++. It was also easy to start using D, because Code::Blocks has support for it, you only have to download the D compiler and point it to C::B.
I was thinking of programming a utility program with D, but it might be interesting to write a small roguelike just to see how different it is to maintain that kind of project compared to C++.
With long experience from programming I can clearly see where D is coming from. It's funny, but in a way D is a result of "bad" features of C and C++, yet I think it's wrong to focus only on those bad features. C++ is just doing things that way. Even C++ developers are breaking in constant pressure to become a "modern" language. Well, I guess those new features can't hurt.
Some features in D are nice as you would expect while others are less useful. For example assert seems to be a strong feature in D, but something I would never use myself. Not in C++ or D. Unit testing is also a waste of time in my opinion. D even has a unittest scope for that purpose. What I found nice is that D has built-in array slicing and easy to use string operations. D doesn't have header files which is one of the ancient structures in C++. It was also easy to start using D, because Code::Blocks has support for it, you only have to download the D compiler and point it to C::B.
I was thinking of programming a utility program with D, but it might be interesting to write a small roguelike just to see how different it is to maintain that kind of project compared to C++.
Thursday, 24 July 2014
Nethack, Angband UI and warm days
I've played Nethack as a researcher trying to find out what makes it good. Of course I've played Nethack even before I started Kaduria (a long, long time ago), but I need to try different professions and also try to become a better player.
The biggest problem in Nethack is Elbereth which kind of fixes an inherent design flaw. Also in my opinion D&D has always been "broken", because it relies too much on magic. But even if the game seems to be broken it can actually create a gameplay that many people seem to like. And it's not fair to judge game design that was created mostly in 80's by regular students. In that context Nethack has stand the test of time very nicely.
Angband is another game I need to study more. I never liked it and didn't even want to learn how to play it. It's still difficult, because the user interface is really bad and tries to scare you away. I remember the old Angband was better (one with true 80x25 console). What they have now is way too many tilesets while they should concentrate creating one good set and ascii modes are also poor, with bad fonts. It's sad how the UI can't even scale to selected font size, you have to increase or decrease the tile size manually.
It's been really warm for over a week now. 25+ C which is extremely warm in arctic region. I'm trying to survive days at work and when I get home do nothing. It's hard to concentrate on programming so I have spent this time playing (or researching as I call it).
The biggest problem in Nethack is Elbereth which kind of fixes an inherent design flaw. Also in my opinion D&D has always been "broken", because it relies too much on magic. But even if the game seems to be broken it can actually create a gameplay that many people seem to like. And it's not fair to judge game design that was created mostly in 80's by regular students. In that context Nethack has stand the test of time very nicely.
Angband is another game I need to study more. I never liked it and didn't even want to learn how to play it. It's still difficult, because the user interface is really bad and tries to scare you away. I remember the old Angband was better (one with true 80x25 console). What they have now is way too many tilesets while they should concentrate creating one good set and ascii modes are also poor, with bad fonts. It's sad how the UI can't even scale to selected font size, you have to increase or decrease the tile size manually.
It's been really warm for over a week now. 25+ C which is extremely warm in arctic region. I'm trying to survive days at work and when I get home do nothing. It's hard to concentrate on programming so I have spent this time playing (or researching as I call it).
Wednesday, 9 July 2014
Field of field of vision
Roguelike developers have long struggled to invent good and fast FOV routines. I've had some good results with a regular line of sight (line drawing) and then fixing errors with a special routine. What I've also found out is that clearing the FOV map first is slower than setting visible and blocked tiles using only line drawing (drawing to the end of FOV area) at least in large open areas, because there are then two iterations through the map (even though line drawing visits a number of same tiles).
One day I had an idea about new type of fix routine that takes place first, before line drawing. It also sets each tile of FOV map to a preset value. Then line drawing takes care of the rest. But let's not get excited, because there is not yet a working implementation. In theory with advanced type of routine it would be possible to limit line drawing only to places where it's needed after the initial FOV routine.
I also wondered would it be possible to draw the level with the FOV routine itself (without having to copy the FOV data first to a map) using an update map to prevent multiple drawing of a tile. It could be something to try, because it seems always that you need to iterate the map or visible area several times to get things done before drawing.
One day I had an idea about new type of fix routine that takes place first, before line drawing. It also sets each tile of FOV map to a preset value. Then line drawing takes care of the rest. But let's not get excited, because there is not yet a working implementation. In theory with advanced type of routine it would be possible to limit line drawing only to places where it's needed after the initial FOV routine.
I also wondered would it be possible to draw the level with the FOV routine itself (without having to copy the FOV data first to a map) using an update map to prevent multiple drawing of a tile. It could be something to try, because it seems always that you need to iterate the map or visible area several times to get things done before drawing.
Sunday, 6 July 2014
The player of games
As a player I'm not very good. It has somehow become more evident when I've been watching ADOM gameplay videos on Youtube by Gordon Overkill. He also seems to make mistakes which fellow youtubers often point out in comments, but he is still way better than I am.
The main difference is that Gordon knows what to do. He knows where to go, what items to use and what kind of monsters there are in the game. Of course roguelikes require learning that stuff and using tactics to apply all that information. I don't play ADOM, but in Nethack it's the same story. What happens to me in Nethack that I sometimes get far, but then something bad happens and the game is over. Sometimes it's something new, but often it's just the lack of proper tactical response to a bad situation. In other words I don't know what to do.
This is somewhat important, because I'm developing games that should be difficult as roguelikes often are. But how can I do that if I'm not a skilled, tactical type of player? I really don't want to set up a closed game testing before release. Maybe I should forget about creating a super difficult game and create the gameplay easy enough for me to win the game. In case of Kaduria it will probably be something that happens anyway, because the RPG system is not similar to D&D.
The main difference is that Gordon knows what to do. He knows where to go, what items to use and what kind of monsters there are in the game. Of course roguelikes require learning that stuff and using tactics to apply all that information. I don't play ADOM, but in Nethack it's the same story. What happens to me in Nethack that I sometimes get far, but then something bad happens and the game is over. Sometimes it's something new, but often it's just the lack of proper tactical response to a bad situation. In other words I don't know what to do.
This is somewhat important, because I'm developing games that should be difficult as roguelikes often are. But how can I do that if I'm not a skilled, tactical type of player? I really don't want to set up a closed game testing before release. Maybe I should forget about creating a super difficult game and create the gameplay easy enough for me to win the game. In case of Kaduria it will probably be something that happens anyway, because the RPG system is not similar to D&D.
Saturday, 21 June 2014
Shops
I'm refactoring Teemu for more random stuff. In the current version some items always appear in some places, but I want to change it that sometimes they don't. But what happens if they never appear?
The mind-boggling realization for me was that if they don't appear you need a shop where you can buy the missing item. So that's why shops exist in roguelikes! I never thought it that way.
So it looks like I need a shop and I have a shop idea fit for Teemu's theme. Creating a shop is some extra work, but I don't think it's going to be too difficult. Earlier someone was wondering why there already are rupees in the game when you can't buy anything. Well, now you know. I just have to sprinkle more rupees than there is now to make sure the player can get the required money to buy items.
The mind-boggling realization for me was that if they don't appear you need a shop where you can buy the missing item. So that's why shops exist in roguelikes! I never thought it that way.
So it looks like I need a shop and I have a shop idea fit for Teemu's theme. Creating a shop is some extra work, but I don't think it's going to be too difficult. Earlier someone was wondering why there already are rupees in the game when you can't buy anything. Well, now you know. I just have to sprinkle more rupees than there is now to make sure the player can get the required money to buy items.
Subscribe to:
Posts (Atom)