Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - tuturto

Pages: 1 ... 15 16 [17] 18
241
Programming / Re: clean code
« on: August 10, 2012, 06:38:29 AM »
Yes, and I'm interested seeing how others write that in a way that the new functionality is easy to add and involves minimal amount of editing of old code. If you check melee1.c in Sil's sources, there's code like:

Code: [Select]
/* Describe the attack method, apply special hit chance mods. */
switch (method)
{
case RBM_HIT:
{
        ...
}
case RBM_TOUCH:
{
act = "touches you";

// ignores armor
prt_percent = 0;

// can't do criticals
no_crit = TRUE;

break;
}

case RBM_PUNCH:
{
act = "punches you";
do_stun = 1;

// stopped by armor
prt_percent = 100;

break;
}

case RBM_KICK:
{
act = "kicks you";
do_stun = 1;

// stopped by armor
prt_percent = 100;

break;
}

which works and is easy enough to edit. But if you wanted to add something new, you would have to add it to that select-case - section, instead of just coding it as a stand alone unit and telling the system to use it.

Or if somebody would want to make a variant, which works pretty much the same as the original system, but kicks (for some reason) are not stopped by armour. In the example, this would be achieved by editing original code. When new version of original code is released, the variant has to merge the two codebases so that they have new functionality of the original plus their changes.

However, if the stuff that variant does differently was written in own location and the engine was told to use that one instead of the original, merging would most likely be much easier.

242
Programming / Re: clean code
« on: August 09, 2012, 03:57:40 PM »
Thanks, I downloaded source for both and started looking around a bit.

On a first glance, Sil isn't quite what I'm after. Code is well commented and nicely structured, but for example describing attack method and applying special hit chance mods (make_attack_normal in melee1.c) has a long switch-case - section, where it is taken care of. If I wanted to add a new attack method, I would have to modify that code, instead of just adding a new class or function and letting the program to know where to find it.

ToME4 looks interesting too, but that takes a bit more poking around to guess what's going on. It's probably closer to what I'm after. In any case, I'll read some more of both sources, it's always interesting.

Krice, by "easily" I meant a system where one wouldn't necessarily have to change existing function / class / what-else-construct to add new functionality, but it would be taken care of in some dynamic way.

kraflab, Epilogue sounds interesting, but can't really source dive that :)

243
Programming / clean code
« on: August 09, 2012, 04:57:00 AM »
I have been poking around with roguelike development for a bit and started wondering if anyone would know really good examples of cleanly written games. I'm mainly looking for a big picture, not so much single algorithms. You know, how to make system for magical effects that isn't completely hard coded or how to add new actions into game easily.

It would be nice if the game had some other documentation than source code too, but that's not mandatory.

Any suggestions or ideas where to start?

244
Programming / Re: implementing speed in projectiles with libtcod
« on: August 06, 2012, 12:26:35 PM »
Well, the difference is that do you want to write SOLID software system or do you want to tinker around with stuff that you don't really know and see if you can get it running and maybe learn something while doing it. Lot of trouble, sweat and tears could be saved if your first roguelike had a really good architecture and sound design, but where's the fun in that?

You can program for living or you can program just for fun (and maybe later switch to living thing if you have so much fun with the code). That's how I started in the 80s, copying from how to write X articles in magazines, changing the code and messing around with it.

The point is that if you just want to mess around with code and get used in programming, you don't have to know who Liskov is. All that stuff can wait for later day when it really matters. However, if you're interested in such things right from the beginning, then it would make sense to read about those too. There's a limit how much new information you can pour into one's head in a given time after all.

245
Traditional Roguelikes (Turn Based) / Re: Herculeum released - 0.4
« on: July 31, 2012, 03:14:06 PM »
Thanks.

It's all more or less improvisation. I know that I want to write a roguelike, preferably one that can be played with xbox controller, but that's about it. I'm writing master's thesis relating to software testing, so experimenting with testing is somewhat important too.

Other than that, I try to code what ever fancy thing I currently think is interesting. Next I should do something about user interface, but PGU library is giving me some troubles with joypad support.

246
Traditional Roguelikes (Turn Based) / Re: Herculeum released
« on: July 31, 2012, 09:05:28 AM »
Title: Herculeum
Summary: Simple Rogue clone written in Python.
Version: 0.4
Released: 2012-07-31
Site: https://github.com/tuturto/pyherc
Online manual: http://tuturto.github.com/pyherc/index.html
Direct download: https://github.com/downloads/tuturto/pyherc/pyherc-0.4.zip

* New user interface started (and almost all existing features dropped)
* Updated documentation
* Pushed code around and split the game into two parts (game and engine)

247
Programming / Re: Beginner's Guide to Roguelike Development
« on: June 08, 2012, 05:34:35 AM »
The articles are pretty nifty and they focus on the very basics, which is good. I think it makes sense to first show simple way to create something and later tell what other options there are or where to find more information. Concepts are introduced in a good order, there is always something new to play around with after finishing reading an article. Person reading articles probably hasn't ever written a roguelike, so the game they'll create probably won't be the last one they write (if they stick to it), thus I don't think doing regular C is a problem.

248
Programming / Re: Debugging and other helpful things
« on: June 02, 2012, 07:37:55 AM »
I think both ways have their merits. More than often it's good to have full control of what actions are taken during test, while sometimes (especially when testing how AI behaves), it is useful to give it a free reign.

Watching AI to play the game can be interesting, but I personally probably wouldn't use it to test the game. I like my tests small, fast and running continuously when I code. But I could probably use it to learn more about the game and how different AIs react to each other and observing if there are subtle bugs that tests don't cover yet (and then make sure that there is test for that subtle bug too when one is found).

I have been playing around on idea of writing some high level helpers for testing and especially for cases when I'm defining how things interact on a high level (ie. get hit by a monster, your hit points should go down, drop a fireball on top of potions, potions should boil and explode). Intent of following test is probably easy enough to understand, even if one reading it hasn't done much (if at all) programming:

Code: [Select]
def test_that_hitting_reduces_hit_points(self):
        """
        Getting hit should reduce hit points
        """
        Pete = strong(Adventurer())
        Uglak = weak(Goblin())
        level = Level()

        place(Uglak, middle_of(level))
        place(Pete, right_of(Uglak))

        make(Uglak, hit(Pete))

        assert_that(Pete, has_less_hit_points())

This is of course a lot simple case than what purestrain showed. I don't have game loop running (since I'm doing a single action). Eventually I need to figure out how to test those things too (making multiple actions and maybe having multiple characters to act even). Having queues of actions could be one solution for this.

249
Programming / Re: Debugging and other helpful things
« on: May 17, 2012, 11:30:31 AM »
Really nice ideas there. I have to try that AI bot thing at somepoint and see what I need to get it up and running. What kind of interface do you have for it Kyzrati? Like, is the bot running inside the game and interfacing it directly or do you have it as an external program that connects to the game in order to play it?

I guess I could expand my debug server to serve json or something equally simple that could describe what the bot sees and then accepts commands from it that it executes. I think it should be fast enough for turn based game like this.

I'm mostly using the random number generator created in the beginning of the program, but I think there are still some places where a new one is instantiated. This makes the game non-deterministic, since current system time is used as seed. I'm slowly removing those from the code though, so after that I can try out running games with same seed.

250
Programming / Re: Debugging and other helpful things
« on: May 14, 2012, 06:29:07 PM »
Most vital: An AI that can mimic the user and be run indefinitely to test the program automatically.

Interesting. You have full game running and the AI is playing it? Or specific scenarios that it replays over and over again? How do you handle asserting that the game is behaving as it is expected?

I'm building my system with test driven development and recently started tinkering with doctest (sort of unit testing the documentation), but really high level stuff I'm lacking. Like move from room to room, while opening the door in between and falling into trap stuff. Would be interesting to try that too.

251
Traditional Roguelikes (Turn Based) / Herculeum 0.3 released
« on: May 12, 2012, 07:38:27 AM »
Title: Herculeum
Summary: Simple Rogue clone written in Python.
Version: 0.3
Released: 2012-05-12
Site: https://github.com/tuturto/pyherc
Online manual: http://tuturto.github.com/pyherc/index.html
Direct download: https://github.com/downloads/tuturto/pyherc/pyherc-0.3.zip

* Potions now affect over course of multiple turns
* Updated documentation on actions
* Test results, test coverage and static analysis are now published online (maybe it encourages me to work more on the quality of code)

252
Programming / Debugging and other helpful things
« on: May 09, 2012, 11:28:26 AM »
What kind of systems/things are you using for helping in development? Things like profilers, debuggers, debuggin consoles within the game and so on? How do you like them and is there something that you feel could be done better?

Personally, I have two things that I use a lot. One is extensive debug log that is written if the game is started with specific command line switch. It uses aspects to log most of the method calls, their parameters and return values. In case of exception, exception is logged too. I like it because there usually is enough information to see how the program is running and where the problem might be. I also don't have to write separate calls to logging system, but it's handled more or less behind the scenes. Drawback is that the log can get big quite fast and finding information in it can be slow.

Second tool that I'm using is a debug server. There's small webserver running inside of the game and I can use it to inspect state of the game. Currently I can only view player character and map, but later I'm going to implement more functionality in it. Maybe things like spawning specific items or monsters to help in testing.

Very rarely I resort to debugging code. I think I have done that only in handful of cases, where I couldn't otherwise solve the problem. Profiling I haven't done much either, only to check occasionally that there isn't obvious bottlenecks where there shouldn't be any.

253
Programming / Re: Ease of Implimentation...Major Consideration?
« on: April 25, 2012, 07:58:18 PM »
If I were to design everythign before starting writing code, I would be basing lot of design on assumptions.

This is not related to programming but game design itself. In other words you need to test some feature to see if it works in gameplay's point of view. But it could in theory work already in the design. I think designing has bigger role when you get more experienced in game development. I guess it's something you don't learn quick.

Yes and no. If I'm giving character class special attack to compensate slower healing rate, I'm assuming that slower healing rate needs compensation and that special attack is good for that. If I'm first playing around with character that has slower healing rate, I probably get idea if it needs compensation.

Granted, the more experienced you are, the bigger steps you can take in designing a game. I'm not Sirlin, so I have to take smaller steps.

254
Programming / Re: Ease of Implimentation...Major Consideration?
« on: April 25, 2012, 10:06:18 AM »
I come up with new ideas and discard most of them in regular basis. Sometimes they don't fit to the theme of the game, sometimes they're hard to design well and sometimes they're too hard or laborous to implement. I'm deliberately not writing huge and detailed design document before writing code, because I believe that well planned is never implemented. Rather I like to design and implement one thing at a time, discarding and editing things as the design grows. The goal is to keep the game design and codebase as good as possible at all times. If I were to design everythign before starting writing code, I would be basing lot of design on assumptions.

255
Traditional Roguelikes (Turn Based) / Herculeum 0.2 released
« on: March 18, 2012, 10:42:07 AM »
Title: Herculeum
Summary: Simple Rogue clone written in Python.
Version: 0.2
Released: 2012-03-18
Site: https://github.com/tuturto/pyherc
Online manual: http://tuturto.github.com/pyherc/index.html
Direct download: https://github.com/downloads/tuturto/pyherc/pyherc-0.2.zip

* New section: Crypt
* Debug server for viewing game state: point your browser to http://localhost:8080/
* Squished some bugs

Pages: 1 ... 15 16 [17] 18