It's actually an old project to which I have designed creatures as a starting point. I've talked something about script-based design before and now it's time to try it. It's a new style for me, but of course used in many roguelike projects since ancient days of Angband.
I'm looking at scripting as a tool to plan stuff before writing actual code. The script is a plan which becomes data when parsed.
This is also a good time to try new SDL 2.0. It's somewhat different than 1.2, but should be manageable I guess. It's better practice with a new project and then use the gathered wisdom to spread on older projects which I think will be converted to 2.0 sooner or later.
This new project is also going to be a roguelike. It has a cool basic idea or theme that I believe will carry over the usual development trouble swamp we all are so familiar with.
Sunday, 18 August 2013
Friday, 9 August 2013
Pixel drawing tool project
Brick Atelier is a tile based drawing tool, but I have wondered if I could take good parts from that project and create a new drawing tool with regular canvas as drawing surface. It would solve some problems you have in tile based style, but also add new features I have never tried to program.
I have an idea for new type of user interface, but I have to try it first to see if it works. User interfaces are cool topic, because there always seems to be something to improve in them.
This time I could also try to think an alternative solution to SDL, because it doesn't have GUI features that could handle stuff like file dialogs. I really don't want to go in that kind of detail I did with Brick Atelier.
I don't know if this is going to happen, but at least I can make some plans on paper of what the user interface should look like.
I have an idea for new type of user interface, but I have to try it first to see if it works. User interfaces are cool topic, because there always seems to be something to improve in them.
This time I could also try to think an alternative solution to SDL, because it doesn't have GUI features that could handle stuff like file dialogs. I really don't want to go in that kind of detail I did with Brick Atelier.
I don't know if this is going to happen, but at least I can make some plans on paper of what the user interface should look like.
Monday, 15 July 2013
The graveyard
The next destination in Teemu is the graveyard, an addition to places in the island. For that I have to create a name generator for graves, but other than that it's just choosing monsters and the usual stuff.
Finished reading The History Of Seafaring, a monumental book written by Donald Johnson and Juha Nurminen. I thought the subject was not that interesting, but that book surprised me. It also gave me much more accurate information about sailing boats than I knew before and there happens to be a boat in Teemu. I think it's going to have some improvements installed.
I try to work on all three main projects: Kaduria, Teemu and Brick Atelier. I don't want to let any of those projects dry out for too long time. It's just frustrating when you get stuck, in projects like this and in life, too...
Finished reading The History Of Seafaring, a monumental book written by Donald Johnson and Juha Nurminen. I thought the subject was not that interesting, but that book surprised me. It also gave me much more accurate information about sailing boats than I knew before and there happens to be a boat in Teemu. I think it's going to have some improvements installed.
I try to work on all three main projects: Kaduria, Teemu and Brick Atelier. I don't want to let any of those projects dry out for too long time. It's just frustrating when you get stuck, in projects like this and in life, too...
Sunday, 23 June 2013
Long message
There are long or level messages in Teemu when you enter a level theme that has it. You have an option to turn them off so I thought it would be good to be able to view last five messages just as regular message buffer. Storing the messages to a list was the easy part, since it's just a std::list in World class.
Programming the display routine took more time. First I had to solve how the window size knows its height, because each long message has different amount of lines. The "formatted" text output routine Write_F actually returns the amount of lines, but the routine to count lines was inside it. Of course you could always detach that part to independent routine, but it's not always that easy when you have local variables. So what I did was just call Write_F for each message and store the amount of lines. Write_F doesn't show the messages unless update is called, so it didn't matter. After that I knew the amount of lines, displayed the window and then displayed messages again on top of that window. Done!
It took about an hour or possibly more to write that routine. A perfect example why roguelike programming is slow. A roguelike can have hundreds of features, all of them waiting for implementation. And not only that, you can break the underlying framework if you need something new for a feature. It can then break some other features. The framework is extremely important, but sometimes it doesn't support something you need and changing how the engine works can be really difficult. This already has happened in Teemu with events that were carelessly mixed in.
Programming the display routine took more time. First I had to solve how the window size knows its height, because each long message has different amount of lines. The "formatted" text output routine Write_F actually returns the amount of lines, but the routine to count lines was inside it. Of course you could always detach that part to independent routine, but it's not always that easy when you have local variables. So what I did was just call Write_F for each message and store the amount of lines. Write_F doesn't show the messages unless update is called, so it didn't matter. After that I knew the amount of lines, displayed the window and then displayed messages again on top of that window. Done!
It took about an hour or possibly more to write that routine. A perfect example why roguelike programming is slow. A roguelike can have hundreds of features, all of them waiting for implementation. And not only that, you can break the underlying framework if you need something new for a feature. It can then break some other features. The framework is extremely important, but sometimes it doesn't support something you need and changing how the engine works can be really difficult. This already has happened in Teemu with events that were carelessly mixed in.
Saturday, 22 June 2013
Scripting hard
Teemu's unfinished features have been reduced from 23 to 16. I guess it's something, but hardest stuff is still to do. Once again I noticed that when you put something else in a class from another type of class as functional part of it it's usually a bad idea. But keeping those pesky classes strictly modular is quite impossible or at least unpractical in game programming.
I had an idea to use scripting in one of my roguelike projects. I guess scripting is widely used, but it's alien to me. I might as well try to go as far as possible and try to describe the game using only scripting. I think the good thing about scripting is that it's easier to stay away from static data structures and create a complete set of data for the game content. Maybe even before you write a single line of code. It's like planning the game content in a form of scripting.
Writing a parser for scripting is the hard part and also creating a game engine that can chew the processed data. It's going to be an interesting project. Or not.
I had an idea to use scripting in one of my roguelike projects. I guess scripting is widely used, but it's alien to me. I might as well try to go as far as possible and try to describe the game using only scripting. I think the good thing about scripting is that it's easier to stay away from static data structures and create a complete set of data for the game content. Maybe even before you write a single line of code. It's like planning the game content in a form of scripting.
Writing a parser for scripting is the hard part and also creating a game engine that can chew the processed data. It's going to be an interesting project. Or not.
Thursday, 20 June 2013
Major issue
In IRDCon of Roguelike Radio was an interesting idea that roguelike is "major" when it has a lot of players. It's of course not like that. I think a strict definition is both unneccessary and funny, but when the game has complexity level of Nethack it can be called a major roguelike. However in my opinion even Nethack is too simple in a way. It has lots of items and enemies, but I've always thought that as "vertical" complexity. The "horizontal" complexity comes from the number of ways you can interact with the items and game world. It's an area that has a lot of room for improvement and I believe it's more important than the amount of stuff. You can have something like 300+ items, but the gameplay can still be extremely simple.
I'm working on several projects, but I haven't abandoned Teemu. It's a nice project, because it doesn't have to be anything like Kaduria which is really a seriously major project. I can put any wild ideas in Teemu and remove too complex ideas that would take too long to create (in the current version). Teemu has 23 issues to solve ranging from minor bugs to entire level themes. It's not that much, but there are always those difficult features that require more work.
I'm working on several projects, but I haven't abandoned Teemu. It's a nice project, because it doesn't have to be anything like Kaduria which is really a seriously major project. I can put any wild ideas in Teemu and remove too complex ideas that would take too long to create (in the current version). Teemu has 23 issues to solve ranging from minor bugs to entire level themes. It's not that much, but there are always those difficult features that require more work.
Wednesday, 12 June 2013
International man of mystery
I heard they were talking about me on IRDCon. I hope it was all good things. Maybe some day I just appear there and surprise everyone. Well, maybe not.
I've cut down my forum time on some regular forums I visit. It's difficult for me, because somehow I have an addiction to forums even things often get into me vs. world situation. I hope the forum time will be allocated on game development in more efficient fashion.
Finally started to work on my new project. I know it's madness, but I need more projects to jump between them or I'll get bored. Besides this new game is a nice idea. It was one of those ideas you get suddenly before falling into sleep. It's almost like you could see the game in your mind's eye, the third one of course.
I've cut down my forum time on some regular forums I visit. It's difficult for me, because somehow I have an addiction to forums even things often get into me vs. world situation. I hope the forum time will be allocated on game development in more efficient fashion.
Finally started to work on my new project. I know it's madness, but I need more projects to jump between them or I'll get bored. Besides this new game is a nice idea. It was one of those ideas you get suddenly before falling into sleep. It's almost like you could see the game in your mind's eye, the third one of course.
Subscribe to:
Posts (Atom)
