tag:blogger.com,1999:blog-61528730001241070322024-03-05T00:36:40.040-08:00Kaduriaroguelike programming blogKricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.comBlogger314125tag:blogger.com,1999:blog-6152873000124107032.post-26389819968017146352024-02-12T11:58:00.000-08:002024-02-12T11:58:15.830-08:00Open source Kaduria?<p>Being in a vulnerable state I thought about making Kaduria open source. Then people would be able to follow the development and get an idea how it works. The only downside is that it would reveal all the secrets of the gameplay. Then again, I could release the source only to a certain point in the development, because believe it or not the content is seriously lacking at the moment, there is not much of it yet.</p><p>There is also a possibility of "variants" emerging, but it's extremely unlikely. Managing source code and project of this type and size just isn't that fun or productive, I know it best myself. I have thought about open source many times over the years, but maybe the time is right now. Still, I would first like to create a minimum amount of content and at least a version of the role-playing system, so people could actually play the game already.</p><p>I wonder if this would be a good idea or not.<br /></p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-76187455533022083432023-11-18T02:58:00.000-08:002023-11-18T02:58:45.038-08:00Obvious invention<p>Previously I thought that some classes just become large and complex, but I was maybe wrong. You can create complex classes and implement stuff that way, but once again I find myself refactoring the code to detach complex "stuff" from classes and moving it elsewhere, usually in functions.</p><p>The big reason to do it this way is that you can create modules (files in C++) with themes which in turn makes project management much easier. As an example I'm moving everything that has to do with creating plants to one module. That way, even if you have more complex C-style function parameter interface, it's still better than distributing that stuff into classes or even one dedicated class. I have some dedicated classes for some operations, but strangely classes don't work well in that role. Classes work when they have (store) associated data and only have one task to do.</p><p>So, how does this change the project's development? I would like to think it does make a difference, because when modules are distinct you can concentrate on some specific task without searching stuff from several files and classes, and possibly also creating duplicate code or algorithms. Functional or procedural action code is easier to understand and I'm still using game object classes in them which means they do implement virtual functions and inheritance, which itself is making complexity easier to handle.<br /></p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-80178212235063011232023-09-26T07:09:00.004-07:002023-09-26T07:11:20.193-07:00Landing objects<p>The project management system was a great idea, one of the best ideas I've had for ages. It's easy to open the project file and check out what modules need fixing and what is the problem in that module.</p><p>Lately I've been working on how objects interact with the environment. If you only had a floor it would be easy, but I made it much more difficult with different types of terrain the object can sink or fall into. In this problem I've had success with good old functions (or procedures which they are in C++ I guess.) For some strange reasons it's easier to detach actions from classes and make them into one monolithic function, something like land_object() which is checking what happens if the object falls on ground (terrain), which can happen in several different situations.</p><p>If the object doesn't drown it's added into a list of "floaters" and processed per turn until it drowns or something else happens. It's kind of unsafe routine probably going to fail some way, but I have no idea how to implement that better way. What gets me is how I have not thought about object landing before? I'm reading the code and finding several unfinished routines for dropping items on water, but that's it. As usual I didn't follow through it. Now it feels like I'm implementing it the first time.<br /></p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-37178088884221293752023-07-05T05:40:00.004-07:002023-07-05T05:41:16.350-07:00Managing the project<p>I think IDEs are missing some project management tools that would make it easier to keep track of stuff. At least the community version of Visual Studio and also Code::Blocks, although I'm using mainly VS to code. I'm so desperate that I'm probably just going to list the files and put them into a spreadsheet, so I can mark them with different colors depending on what state it is. That way you could fix files from least to most important, at least that's the plan.</p><p>When I get back to this project I'm always astonished by it, because it should not be that difficult to handle, really. But for some reason it is. It must be just the amount of files and places that need fixing, there is always something to fix, mostly a result of bad planning. Then again, you can't create good plans if you don't know how to plan something that works.</p><p>I see this problem in other roguelike source codes I'm working on, like Legend of Saladir. You can just see how the developer got deeper into problems of everything falling apart and then gave up. I believe firm project management would help, but the tools that we have for that are surprisingly primitive. Or maybe I have missed some great, possibly free, project management software. Most likely.<br /></p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-21226563854373486512023-03-22T00:55:00.001-07:002023-03-22T00:56:36.066-07:00The new old gui<p>Forcing the gui to the main font size (12 x 24 pixels) was a great idea I think. When everything falls to that "text based" grid it's easier to place stuff on the screen. In fact this is what I partly did earlier with menus having only text based locations, but now everything is locked into the grid, except for smaller font size, but it's also placed "inside" the grid.</p><p>The new gui refactoring has been quite easy, no big problems there. Since the medication has been kicking in I've been wondering now what the google terms of service I've been doing with the gui before. It's like I had no idea how to finish those features, so they were simply left unfinished for a long time. Weird stuff, but then again I certainly had a problem with that brain fog.</p><p>Other than gui I've realized that pretty much everything is important, so there is no special order I have to get stuff in "somewhat" finished state. It's disheartening to understand how much there is still to do in areas like dungeon generation, but I don't find this situation hopeless. Things can proceed fast especially in procedural generation.<br /></p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-7817964238111132722023-02-01T06:06:00.000-08:002023-02-01T06:06:53.107-08:00Graphics conundrum<p>Since I'm off the development until Teemu is ready I have been thinking about tile graphics. The problem is that tiles are small and it's difficult to make them look clean. Besides the last scaling from 24x24 to 32x32 made tiles look smudgy which has to be fixed.</p><p>I have two options and both of them are bad. I can clean up the tiles manually or recreate them in 3D. So I've given more thought to 3D option the more I think about it. The good thing about 3D is that you can scale the tile to pretty much any usable size and always get a sharp result. The downside is that it probably requires more work and creating 3D models for small tile size is not that simple. You can't just create a detailed or even "realistic" model and assume it looks good in 32x32 pixel size, because the details are lost. The model has to emphasize the shapes you want to see in the object clearly. Also, any kind of detailed textures are waste of time, it has to be a coarse approximation of a material.</p><p>I can try and see how long it takes to create a small subset of objects. Either way tiles are going to be a huge amount of work and I'm not happy about the current quality or even style of graphics in Kaduria. However I could even release the game with the current tiles and then slowly remake them.<br /></p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-31002386566903038682022-10-27T02:12:00.001-07:002022-10-27T02:12:09.411-07:00Messages redesign<p>Messages system is giving me a lot of trouble, because the plan for it was not great. It does "work" in that you can output messages, but it's such a mess. I only realized this after writing a debug routine to view messages in a test environment. The issue here is again complexity, as in every difficult part in a roguelike project. You need all kinds of stuff for messages, who is doing and what, is the place near or far, can the player see the event etc. With rigid planning this would have been prevented, but also you need to know special cases which can be difficult to predict.</p><p>So what are the options. Maybe a complete redesign is not that smart, because in theory it works, but I think I need to make it more generic so that message data is working for different object types. The "classic" example is you vs. enemy: "You hit the orc." and "The orc hits you." You need only one message id if you can use "you", "the orc" and "hit/hits" properly in each case.</p><p>For some reason messages have always been a difficult part and the reason is probably just not planning it hard enough. I would really like to use as generic routine as possible, so there are no checks for visibility etc. in the calling routines, because it will increase the size of source code a lot. Also, the usual mistake to make is just go with the routine even if you have a feeling it will not work properly and then you have a bunch of confusing message entries in the data.<br /></p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-10340903115782786052022-01-04T02:16:00.004-08:002022-01-04T02:17:29.723-08:00The plan for 2022<p>The "plan" for this year is the complete design of gui. As boring as it sounds, it's still a part of the game and I've had a lot of trouble with it as well. It mostly follows the rest of development which has been the inability to choose, in this case what to display and how. But as long as I focus on actual stuff rather than source code level implementation it's going to get done some way or another.</p><p>I sincerely hope the gui isn't going to take this year so I can also do some other stuff like dungeon generation (town type levels are still just a dream) and the RPG system. If there is some kind of change in this year it's the knowledge of my shortcoming in focusing on something. I am more aware that it's a real problem and it may even be something like ADHD even though I have not been diagnosed and I'm not willing to get a diagnosis for that type of stuff anyway. What I need to do is to follow through and get things finished, no matter how much they would suck at first.</p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-62523252729798044532021-10-31T04:47:00.003-07:002021-10-31T04:50:59.625-07:00Forest update<p>Previously I had a class called "Area" to create almost anything from regular caverns to forests, but it was simply too generic, because the generation was tied to a cavern. I created a new class Forest that is only creating forests. It has a new type of generation logic based on flood fill which I think works better than just placing trees in a roughly circular area.</p><p>It's quite important to avoid generic routines, because they will become too complicated and for some features may not even work in the end. However the parts should be mostly reusable, like in this context the flood fill routine itself will be reused in other routines that require filling an area.</p><p>Since cavern routine was also using the flood fill which was kind of weirdly modified flood fill it no longer works. This is why you should plan "low level" routines so that they wont break, but offer a true generic way to do something right from the beginning. The division to specific and generic is the main problem in roguelike projects I think, and probably in most projects ever.</p><p>I think a modified flood fill should be ok for a cavern routine, because that's what you want. You want to fill an area but not make it a perfect linear fill, but deviate it to generate irregular shape which still detects the proximity of other features like rooms etc. The proximity value will be a great way to create something like lakes inside a cavern.<br /></p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-14457359177612995322021-05-09T08:13:00.003-07:002021-05-09T08:13:41.387-07:00Feature review<p>They often say you shouldn't have too many features in a roguelike, because they are hard to implement. It is very true, but large scale roguelikes require features and complexity that they give. I went through the source code and listed most major features that are distinctive. There are 64 features and I don't know how it even compares to other roguelikes. The startling or depressing thing is that most of the features are more or less concepts with often minimum amount of implementation. This isn't a surprise, because my inability to decide how features work in detail has been a monumental theme in this project.</p><p>I feel like this is a major problem in many roguelike projects. The design is too simple if you just decide to have some feature like fountains. It doesn't stop there, you need to decide how exactly fountains work and what sub-features they have. Do they dry when you drink from them? Do they spawn monsters? Are there hidden items in them? What happens if you kick a fountain? Is the water always healthy? Etc.</p><p>The sub-features are often linked to the engine thinking, where features either require lots of special code or they should be supported by the engine which then requires more from the engine. Everything adds to the total amount of code which can already feel overwhelming just with the core of the game.</p><p>I think the list of features is going to be my next goal where getting at least the basics working would help get the project to the next level.<br /></p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-90449961409777504752021-03-13T00:06:00.001-08:002021-03-13T00:09:03.411-08:00Dungeon update<p>Or is it an update from a dungeon. The terrain rewrite was not that difficult after all, but the terrain object spawning doesn't work yet. However the engine is good enough to not care about that. I think the rewrite was worth it, because everything seems to work better just like that.</p><p>While the RPG system is still causing problems I've decided to at least finish the dungeon generation. The main problem is the unorganized complexity which I'm cleaning up. Then after that it's simply the design: what stuff to put in what level themes. You would think that roguelikes as "randomly" generated games don't need level design, but nothing could be less true than that. In a way there is more work and more design thought put into a level than in static level design.</p><p>My current day job is only three days a week so it's giving me extra two days to work on my projects. And the way I was kicked out from now-SJWarriorized roguelike "scene" has given me more motivation to show what real roguelikes are when you know exactly what you are doing. This SJW/woke thing is also happening in commercial game development scene which is causing really funny things to happen like companies hiring so crappy developers they can't even create anything. Companies end up losing tons of money and I'm just watching it and eating popcorns.<br /></p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-90533062035787166382020-12-12T02:06:00.001-08:002020-12-12T02:06:38.262-08:00Terrain map rewrite<p>Some time ago I had an idea to create a game object for terrain tiles as well, because it was easier to handle game messages, damage to terrain etc. But it was kind of a mistake which I'm now going to fix with another rewrite (or refactoring, how you want to call it). At this point even rewriting doesn't feel like a problem, because it's mostly rearranging source code to more logical units.</p><p>The new plan is a terrain map with Tile class tiles which is a more complex way to use an integer to show which terrain tile is in that place. With that you also need fov and automap data and so on. Then, when a terrain is changed (most often when damaged) a terrain game object is created in that place. This is going to solve another mistake I made when I removed location data from some game objects. It became incredibly annoying to work with objects that had a location and others which didn't.</p><p>I think it's important to rewrite when you feel something is not right. The irony in this case is that I got it almost right the first time, but then made a decision to rewrite it because the strange problems I had (and still have) with the game message routine. Game messages shouldn't affect the way terrain map routines are implemented at all and it's an important lesson. Each part of the system should work more or less independently at the internal level and external connections should not rely on that.<br /></p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-81502320969908416102020-11-22T03:12:00.002-08:002020-11-22T03:12:46.845-08:00300 Days<p>The latest development idea I have applied to all my main projects is extremely simple but it seems to work in its own way. I've created a five-step rating for source files, which in C++'s case is usually the combination of header and .cpp file. The ratings are: ready, works, test, unfinished and sketchy. For example if the contents of file (usually a single class per file) require testing, I'm adding a line to the header file with #. Then I can search and list all files with that rating.<br /></p><p>What I have noticed with #test files is that testing is way too underrated in development, at least in my experience. The "usual" way to test is I guess play the game and see if it seems to work ok. But I think it's more useful to test individual classes and see if everything works as it should. It's much more work, but when it's done you can move from the test level to "works" level, narrowing down the development size of the project.</p><p>Another good thing with this approach is that it gives a focus on things you need to implement and improve. You can't leave things "for later" if you want to move on the next level. Also with this you can have an estimate of how long it takes to move all files to let's say works level. In Kaduria the starting point with the rating was 309 days, if you give each level one day of development time which is reasonable. It underlines how the size of the project itself makes it difficult to finish a large scale roguelike in short amount of time and why games are usually created by a group of people.<br /></p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-45668166260846647042020-08-14T01:55:00.003-07:002020-08-14T01:58:58.824-07:00Those pesky mazes<p>Creating a maze or labyrinth routine is harder than you would think. At least when you go rogue from "homogenic" maze routine to more free style. The way I'm doing it is first create rooms that are special locations you need to find within the maze, then the maze system itself which is kind of corridors connecting those rooms. The problem is that maze can stop creating itself when it runs into a dead end created by itself. Currently I'm trying to solve this by creating several maze pieces that continue from current maze tiles, making sure everything is connected. However sometimes the maze simply doesn't reach all rooms, but it's possible to fix that by checking out if a room has a connection and then creating a "tunnel", which looks like someone had tunneled through the room walls and everything. It's the simplest solution, although you could create more sophisticated corridor routine as well. In this screenshot green corridors connect rogue rooms to the rest of the maze:</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjgLm3IIx6krB13HmPVPwYl0Dm30-3FVwL54rDcj3_1j5XTmu9juYM6CBtRnjNE7jeJE1vFzWOJDB1Y29V9B0tY0HHej-qd4QZEnZyQ4KQEiwSIiCwK4Ir_nK2n8lBYEtfS0E8Wi_oQ-A/s500/mazeconnects.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="494" data-original-width="500" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjgLm3IIx6krB13HmPVPwYl0Dm30-3FVwL54rDcj3_1j5XTmu9juYM6CBtRnjNE7jeJE1vFzWOJDB1Y29V9B0tY0HHej-qd4QZEnZyQ4KQEiwSIiCwK4Ir_nK2n8lBYEtfS0E8Wi_oQ-A/s0/mazeconnects.png" /></a></div><p>So it seems like everything is ok and there is often even room for additional features. But of course there is a special condition where maze creation fails, which I guess could be easy to fix. It happens when the maze begins from a room close to wall and stops short, then fails to find another starting point from the piece of short maze. Not yet certain why this happens, but even it does the level "kind of" works with tunnels connecting everything else, like in this example:</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHVYlvvKyZHW9purOOZ8vWGiRq8WObNRm6XkXXvoD-4bfye4jsFcwbFtuZn2sTgChzOpQoojEJPHpg5lmB8qpQJhDwiSPPqL3Ie4JLKrcXkqGiSk0jhpKxTncH2GLz2IBPaJdSW07Upg/s486/failedmaze.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="485" data-original-width="486" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHVYlvvKyZHW9purOOZ8vWGiRq8WObNRm6XkXXvoD-4bfye4jsFcwbFtuZn2sTgChzOpQoojEJPHpg5lmB8qpQJhDwiSPPqL3Ie4JLKrcXkqGiSk0jhpKxTncH2GLz2IBPaJdSW07Upg/s0/failedmaze.png" /></a></div><p>It could be possible to add Cornucopia system on top of this and still get a level, but it would not be a maze. I need to fix this last bug and then move on. My recent development strategy is simply go through each issue and keep fixing it until it's decent. That way I'm no longer pushing difficult problems to distant future.</p>Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-27418924661603823572020-06-24T09:38:00.001-07:002020-06-24T09:40:14.630-07:00Static code analysis reportWith Kaduria I have not been consistent in checking code quality until now. I was thinking that it can be done "later" when the project is in testing phase and using code analysis on such a large project can be tedious. But I have since then began to run at least CppCheck on the whole project.<br />
<br />
The nice feature of static code analysis is that you can find some bugs for free. There is no need to find them yourself and waste time on that. It also improves code quality when you can remove unused functions and other things like that. Some warnings like missing <i>explicit</i> and <i>override</i> keywords can be annoying, but adding them also is an improvement in code quality.<br />
<br />
The tools I'm using are CppCheck, Visual Studio's W4 warning level and static code analysis with clang option (you can turn it on in project settings). There are some commercial tools which could be nice, but I don't have the money for those, at least in scope of money I'm getting from game development (which is 0.00€). GCC has also compiler settings for static analysis, but at the moment I don't have GCC installed and for that I would have to figure out a way to compile Kaduria in GCC in clean way.<br />
<br />
Static analysis is good at finding errors in logic like comparisons which are always true or false, but more complex things would possibly require some kind of artificial intelligence to detect the problem. Maybe it is the future of analysis tools.Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-90313071384266219192020-05-19T04:52:00.000-07:002020-05-19T04:52:15.657-07:00Progress and ideasSomething snapped in my brain a while ago and as the result I have almost completely stopped refactoring source code in all my projects. It means that the focus is now on the game design. I also figured out how to combine physics and traditional RPG system which also was a sudden realization.<br />
<br />
Physics simulation in games is kind of weird subject, because games can never be completely physics based. If they were it would ruin "the hero" aspect of games, where the player character always seems to have some kind of special advantage over everything else. For example in most games the player never runs out of gas, but is always ready to do whatever it takes. Some games have a kind of stamina, but it's always limited to a certain level. The plan for Kaduria is not only have more realistic stamina effect but also long term fatigue which means you have to sleep to regain it.<br />
<br />
There are lots of other ways I'm going to change the gameplay compared to a typical roguelike or a role-playing game. I'm not even sure if it's going to be a better gameplay, but I'm just so over the traditional style of roguelikes in particular where everything is based on getting tons of stuff (which in realistic terms you would never be able to carry anyway), killing thousands of monsters just like that etc. In Teemu I have deliberately chosen a traditional approach, because it's not a serious game, but Kaduria will be different.Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-35388073183781691012020-05-02T00:39:00.000-07:002020-05-02T00:39:09.652-07:00User interface stuffI feel that this project is going to be somewhere between old school ascii and "modern" graphical styles in the way how information is shown on screen in the main gameview. In traditional roguelikes you often have information packed in various status lines etc. which I guess become easier to understand once you get used to it. However it feels like mirroring that to a graphical roguelike isn't the best, or having packed information at all.<br />
<br />
Graphical games can have icons to replace text, but in many cases it's worse. In any case, how much and what information is directly on screen is a matter of design which is harder than it seems. User interface design is difficult in all programs, not just in games. Luckily I've learned from my past mistakes and now adding something only if it's easier to have on screen all the time. But it's also a design decision, especially now when you have the space, assuming the gameview is small enough that space for stats etc. is available.<br />
<br />
The design of "off-screen" information is just as important, and making it easy to access can remove the need for on-screen information.Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-19318695688889127842020-04-16T02:00:00.000-07:002020-04-16T02:00:00.622-07:00Plant simulationIt looks like I have to rethink plant growth simulation, because it was too simple to work properly. If you can set up plant simulation it's one of the only places in roguelike development where you can then reduce the work in random generation by some dramatic amount. But for that to work the simulation needs data which is consistent with the dungeon layout, everything that contributes to growth of plants.<br />
<br />
That's actually all I have to say about it. Well, other than in Kaduria the plant simulation is going to be quite detailed, because the amount of data the environment has. I'm not looking forward in clearing the mess I made, but when it's done at least something should work in this project.Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-9239157154368180242020-04-03T00:35:00.001-07:002020-04-03T00:36:51.803-07:00Namespaces and enumsI think I have not yet figured out how to use namespaces properly. Previously I often created a namespace for enums, but it does create problems with names especially if you open the namespace. If you put an enum into class it's much safer that way, because it exactly ties the enum into that class. It also removes the need to add another namespace for stuff, which in large projects is important, because anything you add into the project makes it harder to maintain.<br />
<br />
Currently I'm using more generic namespaces to store data and sometimes functions. For example there are low level text routines in 'codex' namespace and data in namespaces like 'creaturedata' and 'itemdata'. The data in Kaduria is often simple structs which again is probably not the best way to handle it, but it's what it is. The way I now see namespaces is more like a tool to keep track of data and not so much to isolate it from global scope which in C++ is a bit overkill anyway, because you can access only the stuff you include in a .cpp file.<br />
<br />
I guess the "proper" way to use namespace is how std:: namespace is used in standard template library, which is to denote a super large library. But the way I'm using namespaces seems to work, at least it doesn't add more confusion.Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-86440207428060511662020-03-08T11:30:00.003-07:002020-03-08T11:31:33.213-07:00Three structure typesIt looks like the way I'm programming is reaching some kind of goal with how I'm now using three types of "structures" to manage a large scale project. First is type-style class, a small class with often only one variable, or something like Point or Rectangle classes. Creating your own types should be a priority in object-oriented programming anyway so I'm creating them when it makes sense. Which is almost always over using regular types. A great example is Point class, it's way better to create a class that holds x and y variables rather than use them as integers.<br />
<br />
Second type is a regular class, not a type class but larger with more data and components. These are things like monster, item and level classes.<br />
<br />
Third type is a procedure, which in C++ is just a function outside any class. Somehow I find these really useful in parts where you need some kind of action with object instances.<br />
<br />
With these it feels like nothing is missing and I'm able to manage the source code better than ever before. Also, I've largely began to disconnect classes from "modular" files. I find that modules are useful, but only when you have a small class hierarchy (inheritance) or similar types of classes. For example I have Point, Coords, Rectangle and some other similar classes in one file, because they inherit from each other. You need to include the base classes anyway if you want to use any of them.Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-53488947258627971192020-03-01T01:00:00.004-08:002020-03-01T01:02:51.493-08:00The RPG systemMost of the problems in this project seems to be in developing the role-playing system. It's a "simple" concept, most RPGs have some variables like health that is determined by monster type or internal stat like strength. But it's still complex enough to <i>actually</i> implement a new system without just copying an existing one. Even when you don't use an existing system it's still probably going to have health, stamina and the usual suspects.<br />
<br />
Maybe that's the issue I have with it, I'm trying to think about how not to create just another RPG system. One way to try is more "realistic" system which is always going to fail, because realistic games just don't work, the player character has no chance to survive for long in that type of game world. Yet, I think some developers are annoyed by the fact that RPG systems are simple in the outside and they make the gameplay feel too much like you are working with numbers, and tactics revolve around trying to figure out how much HP the enemy is going to take in one turn etc.<br />
<br />
However if I want to finish this project it's largely depending on RPG system which I now know is the core of a roguelike game, while many developers like myself focus too much on game world development (random generation routines) and leave RPG system as an afterthought. In a way this has been even more difficult to me, because I never really was that highly tactical player that can squeeze everything out from the resources you have in the game. Maybe the gameplay could reflect that philosophy by reducing the amount of close combat or even creating alternative ways to handle combat situations. In most radical solutions you could remove "mandatory" combat and create safe areas in the dungeon you could travel, leaving combat as an optional feature.<br />
<br />
Whatever the solution will be, I doubt it's going to be a basic RPG system with a basic roguelike game. I would hate to create a game like that while other developers are just fine with it.Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-78333656963209018812020-01-19T02:18:00.001-08:002020-01-19T02:21:02.316-08:00Is this... refactoring?I think it is, but in a nice way. At least it doesn't feel that bad, and it's more like re-arranging the source code. The first step was actions as procedures, but it's also possible to create classes with an outlook at the basic data. For example today I programmed a look command to an external class Look. It takes in Level and Avatar (aka player) data and then determines different ways to look at things. The source code was largely previously both in Level and Avatar classes which increased their size and distributed functionality in lots of small member functions.<br />
<br />
In comparison the Look class is focused and has only <i>one</i> public "entry point" function. This prevents confusion when you pass the data into class almost as if it was a procedure. From maintain perspective it's also easier, because when you need to fix something in looking you know where to find everything. Only low level routines are in Level and Player classes to return some atomic piece of data.<br />
<br />
I don't know, maybe it took a good while to realize that actions should be detached from classes like Level to keep them simple, in cases where actions need two or more (large) classes in them. And also, that <i>procedural style</i> can be better in some situations which, undoubtebly, has been a troublesome concept for me to accept, since I have been such a fan and connoisseur of object-oriented programming.Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-27820051731485178692020-01-07T07:20:00.000-08:002020-01-07T07:20:00.980-08:00Actions in actionNow that I have programmed some actions as procedures it becomes clear how nice it is. And, since they largely maintain object-oriented paradigm it doesn't even break the code that way. It's almost like calling<i> </i>a library function from a class. It's great how actions like kicking or digging can be reduced to one linear function which is much easier to manage than when the code is spread in classes. It's such a simple concept, but it works.<br />
<br />
This brings back an old argument that C is "better" than C++. In this case I would say it sure seems like it, but obviously it's not the whole story. Managing data and resources in classes is certainly better than C's procedural style.<br />
<br />
The actions.cpp has 6 functions at the moment and it's 367 lines of code. I'm planning to keep everything in one file, because it seems quite fitting when they are only functions. The final size can be anything, but I doubt it will be an impossible amount of lines. The number of lines in this project is moderate, because the excellent quality of the code.Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-74192731686288604872019-12-30T03:45:00.001-08:002019-12-30T03:45:03.634-08:00Actions as proceduresThere is one more technical thing I've tried and it actually works. The background for this "issue" is the way OOP can <i>fragment</i> the code if you need more than one class where any particular class doesn't have a "major" role. It can also be fragmented by inheritance.<br />
<br />
If there is a complex action it can become quite annoying to implement in OOP fashion, but in C++ you don't have to, since it's a multi-paradigm language. A real life example is digging with pickaxe. It's happening both in Level class and Creature/Player class, but when you create a procedure (I'm trying to avoid the word 'function' here, because there are functional programmers stalking everywhere) and in this case only one procedure which takes Level, Creature, digging item and direction as parameters, it removes the confusion by unification of the code.<br />
<br />
A procedure solves more than one problem. First it's making the code less fragmented and in this case the procedure becomes a linear collection of actions. It's also removing code from Level and Creature classes which often become large and difficult to maintain. Not only that, with C++ you can take care of a procedure not breaking OOP, because the procedure can use class code without any side effects of regular, non-functional style.<br />
<br />
Obviously you could do this with OOP as well, using a special class to handle this the same way, but it's the exact same thing. Where this works really well are actions such as digging, but then again it does solve only a particular problem of complex structure. OOP in general is better for low level code, handling data etc.Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0tag:blogger.com,1999:blog-6152873000124107032.post-9449253417766402672019-12-15T13:28:00.001-08:002019-12-15T13:29:22.073-08:00Year 2020 for KaduriaRecently I've done right things and this project is going forward even it doesn't seem like it. The development is clearly shifting from technical stuff to content. I predict that 2020 will be difficult to Kaduria and also myself, because I have some real life problems. Well, the biggest problem is money as usual.Kricehttp://www.blogger.com/profile/07789939511437441094noreply@blogger.com0