MURK - a small preview

This is a discussion on MURK - a small preview within the Game Programming forums, part of the General Programming Boards category; > Will it have the same gameplay as netHack? Can I hack my way from the save files? Nope. The ...

  1. #16
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,438
    > Will it have the same gameplay as netHack? Can I hack my way from the save files?

    Nope. The game will allow you to load other savegames files, allowing you to go back if you get in trouble. The purpose is not to make it difficult to finish the game. The game never ends. However, all data in the database and save game files is encrypted. It won't be easy to edit the files.

    > hope your strings are in resource files... for easy translation

    Unfortunately no. I thought briefly about it. But decided to make my life easier on that matter. The game is all in English. To be able to translate it, one has to edit the source files and the data file.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  2. #17
    verbose cat
    Join Date
    Jun 2003
    Posts
    209
    Quote Originally Posted by Mario F.
    Some Game Features and Screenshots:
    ...
    • Never-ending world. Areas adapt to player level.
    • Never ending experience. Player has unsigned long * char levels to acquire.
    You slice through the Ultra Giant Super Mega godlike alligator, dealing 12,093,317 damage.
    Congratulations, you have killed the Ultra Giant Super Mega godlike alligator! You gain 4,546,921,958 experience!
    Congratulations, you have gained a level! You are now level 9,952,124.
    You now need 8,416,749,218,019 for next level.

    <6,594,432/12,195,207hp 1,293/1,293mag 110/250mv>


    I SOOOOO want to play this game! heehee

    What MUDs have you played? Not so much the particular incarnations, but which codebases have you played? I tend to be a Diku fan, but that's mostly because I've researched more about Diku than LP in my own effort to do this. (I am maybe 0.02% complete thus far! And in a mere 4 years, I'm sure I'll be done with it in no time!)

    Seriously, how will you deal with this kind of silliness? I like the idea of the game never ending, but what happens when you get your character up to level 9 million? With a little luck, I'm sure someone, somewhere could do it, just to do it if for no other reason.
    abachler: "A great programmer never stops optimizing a piece of code until it consists of nothing but preprocessor directives and comments "

  3. #18
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,438
    Quote Originally Posted by jEssYcAt
    What MUDs have you played? Not so much the particular incarnations, but which codebases have you played?
    DikuMuds mostly, mainly the smaug codebase and other merc and merc derivatives. However I did start in the late 80s with an AberMud. I moved shortly after to the LP codebase, but couldn't resist the Diku's, especially when the Merc codebase first showed up. Had play them ever since.

    I don't play for 3 years now. I stopped playing them. I feel that by the late 90's they lost much flavour. I don't know exactly why. I have a few guesses. But I don't play muds anymore.


    Quote Originally Posted by jEssYcAt
    Seriously, how will you deal with this kind of silliness? I like the idea of the game never ending, but what happens when you get your character up to level 9 million? With a little luck, I'm sure someone, somewhere could do it, just to do it if for no other reason.
    I don't think I will be able to provide a serious balance at high levels without a couple of years into the development of the game. No matter what I can come up with, only after revisions due to player feedback and a lot of testing will I be able to achieve this. And even then maybe not in a way that covers all aspects of the game. So, it is quiet possible that the first releases won't be playing well into advanced levels.

    Level advancement in the game is slow. Not slow enough to discourage people, but slow enough to not make MURK (the name will probably have to change, btw) a less level dependent game.

    Anyways, here are some of the pointers:

    - Level advancement happens in function of the current level. As you advance in levels, you will see it harder to gain new ones. Internally the XP gained is calculated normally and then a percentage of it is removed based on your current level. I haven't devised the function yet. But it will have some result towards 0 while never reaching it. So this will effectively restrain new levels at higher ranges, or make them extremely hard to get. The trick will be determining the frontier at which gaining new levels becomes extremely hard.

    - Player attributes (strength, constitution, etc...) are fixed on a range of [1,20]. Player skills (axes, hand-to-hand combat, double-damage, etc...) are fixed on a range of [1,100]. Player advancement is such that in order to have all skills at 100 you would need an inordinate number of levels. Players will want to specialize instead.

    - Damage in combat is never affected by player level. It is affected by weapon damage, player skills, player attributes and weapon modifiers (see bellow). As such damage is capped since all these elements are.

    - Areas will be loaded according to the player level within a certain range. Particularly the monsters that are a part of those areas will be of three types; trainers, free, and ntrainers. Trainers will advance as the player does, these monsters will always be at a level difference from the player as when they started playing the game. Free are random. They have a chance of becoming trainers when loaded. Ntrainers are never trainers. They will always have a fixed level, skills, attributes and equipment. Areas themselves will also be tagged Training, Free, and NTraining. So, a trainer in a NTraining area will never become a trainer.

    Of course, many other things can eventually be added to this still simplistic approach. One of the obvious problems I will be facing is how to get a player long interested on a never-ending game? Especially a single-player one!

    I have no answers for that. Either I will be lucky enough and hit the jackpot, or I fail and players loose interest in it quickly enough. The second more probable choice will nevertheless help provide insight into what I can change. However, some things have already been devised..

    - Complex (ala Diablo II) object generation system with prefixes, sufixes, specials, sets and uniques. This system will be one of the things that will probably give more work and will need to be constantly refined and added to. I have to design it right the first time or it will be an headache to maintain.

    - Area Design needs to be scripted and some form of Area Design mechanism needs to be implemented outside the game, so that players can contribute with their own areas. For now I have no idea how I will achieve this. I've been taking a look at Lua and CINT. But regardless the system needs to be somewhat similar to LPC and others, where areas can be designed with only a marginal learning-curve.

    - Random and Non Random areas. Some areas will be randomly "drawned" and monsters loaded from a pool of allowed beings when the player enters them.

    - Character development needs to be complex in order to be appealing. I have a few novel ideas around this based on my long pen-and-paper RPG experience, from D&D to universal systems like GURPS, or highly exotic systems like Vampire the Masquerade or Call of Cthulu.

    EDIT: Ermm... sorry for this becoming so long. I felt like talking about it. I never actually talked about the game with anyone and maybe I will draw criticism and new ideas this way
    Last edited by Mario F.; 12-12-2006 at 07:13 AM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  4. #19
    verbose cat
    Join Date
    Jun 2003
    Posts
    209
    Quote Originally Posted by Mario F.
    DikuMuds mostly...I moved shortly after to the LP codebase, but couldn't resist the Diku's, especially when the Merc codebase first showed up. Had play them ever since.

    I don't play for 3 years now. I stopped playing them. I feel that by the late 90's they lost much flavour. I don't know exactly why. I have a few guesses. But I don't play muds anymore.
    Perhaps I didn't play enough different MUDs, but it always seemed easier to get into a DIKU, probably since they are all pretty much based on the same foundation. When my favorite MUD went away I started looking for others, but the most common thing I found was "yet another mud started up just so the admin could run his own mud." Between that and not having a lot of free time the last 4 years (hmm, my son is 4, I wonder if there's a connection?) I haven't mudded for a while either. But I have been working on my own here and there.

    Quote Originally Posted by Mario F.
    - Level advancement happens in function of the current level. As you advance in levels, you will see it harder to gain new ones. Internally the XP gained is calculated normally and then a percentage of it is removed based on your current level. I haven't devised the function yet. But it will have some result towards 0 while never reaching it. So this will effectively restrain new levels at higher ranges, or make them extremely hard to get. The trick will be determining the frontier at which gaining new levels becomes extremely hard.
    This is an interesting idea. Sort of a logarithmic progression, like award = xpvalue * (log(level)*.625) or something.

    I see the possiblity of requiring a HUGE INT class or something for keeping track of xp earned for those stubborn players who somehow, after 12 years of playing, manage to get their characters up to 500,000th level. heehee


    Quote Originally Posted by Mario F.
    - Player attributes (strength, constitution, etc...) are fixed on a range of [1,20]. Player skills (axes, hand-to-hand combat, double-damage, etc...) are fixed on a range of [1,100]. Player advancement is such that in order to have all skills at 100 you would need an inordinate number of levels. Players will want to specialize instead.

    - Damage in combat is never affected by player level. It is affected by weapon damage, player skills, player attributes and weapon modifiers (see bellow). As such damage is capped since all these elements are.
    I like this. Paying special attention to the attributes of the equipment in the game is important. It would be disheartening (even if I never actually realized it since the machinations are hidden in the code) if I maxxed my strength, maxxed the relevant skills for the claymore and fighting with it, found the most powerful magically enhanced claymore, managed to get enhancement spells or potions, and make that once in a lifetime stroke against the dragon only to have the damage I deal reduced simply because there is an arbitrary cap on how much damage can be done in one hit. Making sure that only the greatest combination of those things together will deal more damage than you have in mind for one hit will keep things sane, but also reward me when I, after 400 hours of playing and figuring things out, manage to acquire that magical collection of circumstances and equipment.

    And keeping the character attributes limited is good too. Afterall, if a character could achieve a strength of 1,000, but started out with a strength of 16, either he started out like an infant (and so how the heck did he survive any of his fights??), or he now has muscles on the muscles on the muscles on the muscles...on his toes!

    Quote Originally Posted by Mario F.
    - Areas will be loaded according to the player level within a certain range. Particularly the monsters that are a part of those areas will be of three types; trainers, free, and ntrainers. Trainers will advance as the player does, these monsters will always be at a level difference from the player as when they started playing the game. Free are random. They have a chance of becoming trainers when loaded. Ntrainers are never trainers. They will always have a fixed level, skills, attributes and equipment. Areas themselves will also be tagged Training, Free, and NTraining. So, a trainer in a NTraining area will never become a trainer.

    - Area Design needs to be scripted and some form of Area Design mechanism needs to be implemented outside the game, so that players can contribute with their own areas. For now I have no idea how I will achieve this. I've been taking a look at Lua and CINT. But regardless the system needs to be somewhat similar to LPC and others, where areas can be designed with only a marginal learning-curve.
    So this won't be a dynamically generated "dungeon". One of my favorite things in MUDding was to explore and map. What about having some dynamically generated terrain if the builder of an area wants it? This could be something like the king's hedgemaze, which he has re-arranged on an almost daily basis and then challenges people to solve the maze.

    I have wanted to create a Roguelike since I found my first rogue.exe on a BBS while I was in high school. I spent many, many hours trying to get to the bottom of the dungeon. heehee You are making me want to jump back into designing it.
    abachler: "A great programmer never stops optimizing a piece of code until it consists of nothing but preprocessor directives and comments "

  5. #20
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by Mario F.
    - Level advancement happens in function of the current level. As you advance in levels, you will see it harder to gain new ones. Internally the XP gained is calculated normally and then a percentage of it is removed based on your current level. I haven't devised the function yet. But it will have some result towards 0 while never reaching it. So this will effectively restrain new levels at higher ranges, or make them extremely hard to get. The trick will be determining the frontier at which gaining new levels becomes extremely hard.
    You also need a threshold to prevent the gained experience from every becoming 0. Also, getting less and less experience, intuitively, sounds to me like it would be discouraging the player. On the other hand, going the Diablo way and requiring more and more experience points to gain levels, while keeping the actual gain from monsters rising less quickly. (But still rising - hard monsters must be worth more than easy monsters, or the players will go XP hunting against monsters that could slash at them for minutes without doing serious damage.)
    I think the required experience for level-up in Diablo2 was an exponential function, while the gained XP from monsters might have been a polynomial one.

    The first character on Battle.net to reach level 100 was a barbarian played by a team of players, who kept him up pretty much 24/7 - and always going for the final big boss, as Diablo was worth the most experience.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #21
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,438
    Definitely something to ponder. I don't want the game to fall back in either playability and interest once a player reach high levels (still to be determined what an high level is). The advantage of a simple exponential function is that it's quick to run and simple to implement. However, truth be said, performance issues is something that will not be bothering much on an ascii game

    On the other hand it is probably too simple to be a good solution. And certainly I have to consider other possibilities. The "diablo way" seems a good option.

    Another one, of course is to get rid of levels entirely. Something that I always wanted to do, but could never figure out a good way to go about this. The prospect of having a character evolve more naturally always attracted me. Skills can develop themselves over time as the player uses them repeatedly, and get lower as they don't. Attributes can evolve more or less the same way, but here things get much, much, trickier.

    The few games I learned about that used this system always failed to make it interesting enough at some point. Either it was too slow, too fast, too difficult, good for a while but then unrealistic...

    I have the whole time in the world so I'm not entirely discarding this possibility. Especially since I have one idea that I will provide on a separate post on this thread for anyone wishing to discuss.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  7. #22
    verbose cat
    Join Date
    Jun 2003
    Posts
    209
    This got a bit longer than I expected, and I am used to AD&D which is probably obvious.
    Quote Originally Posted by Mario F.
    Another one, of course is to get rid of levels entirely.
    How about assigning a skill level to everything instead of one single, abstract, character level. All skills would start out at 0 and increase with use or training up to a maximum of 100, and all skills decay over time. 20 pts is considered proficient with a skill, and anything less than 20 would have a penalty to the attempt to use the skill (and some skills perhaps cannot be used at all under 20 pts).

    There would be groups of skills that are related and affect each other, for example a combat group could be something like:
    fighting - abstract skill encompassing general fighting, adapting to foes, intuition, etc.
    fighting styles:
    - unarmed (brawling/boxing/wrestling/martial arts/etc)
    - fighting with natural weapons (claws, tusks, bite, tail attacks, etc)
    - 1 weapon fighting
    - 2 weapon fighting
    - weapon and shield
    - 1h weapon fighting
    - 2h weapon fighting
    - fighting in armor
    weapon groups
    - axes
    - swords
    - etc.
    specific weapons
    - claymore
    - main gauche
    - morning star
    - etc.

    A character fighting with a mace and a shield wearing full plate armor for example would gain bonuses to hit from his skills in the mace, maces group, weapon and shield style fighting, armored fighting and general fighting. It would take that character a lot of time, training, practice and experience to become the ultimate maceman, and somewhat realistically his skills in the related areas would spill over if he picked up a sword for the first time. Not being proficient with the sword would mean he would have a penalty to hit when using it, but his skills in the related groups would allow him to improvise and perhaps still be better with a sword than a character who is proficient with the sword but not as skilled in general combat. Much like a veteran warrior who never used a particular weapon will know how to use terrain, deception and many other things to his advantage to offset his disadvantage with that weapon, while the apprentice who trained and specialized with that particular weapon only knows that weapon since he hasn't done any real fighting.

    Other groups of skills could be drawn up, like spellcasting related skills, tracking skills, social skills (think bluffing, intimidation, etiquette, etc.), thievery, research, etc..

    When the character is made initially, you could have templates for different character "classes", so a warrior template might focus on combat skills, a thief class might dabble in a few combat skills and focus more on thievery and information gathering type skills, a wizard class would focus on the spellcasting skills, etc. Or for more control, the player could be given a set number of points to distribute among the skills as they desire the character to start with.

    For a character to gain a new skill, they would either need to find someone to train them, a library to research the skill in, or just start trying to use it (and failing frequently).

    As a character uses a particular skill, her mental attributes determine how quickly that skill improves. One system like this I found neat was that whenever a skill was used successfully, she got the benefit of that skill. But when she failed the skill, an intelligence check was made to see if she learned from her mistake. If she did, then that skill improved. This rewards high intelligence with faster improvement of skills, and slows the improvement naturally as the skill increases.

    The decay of skills could occur as a function of time vs. wisdom perhaps. Something like for every game day that passes a wisdom check is made for each skill. Each skill that fails this check goes down by 1 point. This would prevent all the skills from just going down uniformly every day (or week, or month, however quickly you decide to make skills decay). This would reward high wisdom with slower decay overall. Or to make skills decay even more realistically, the game could keep track of the last time the character used a skill. If the skill was used in the last 24 game hours, then it would skip the check and it would not decay. But for each game day the skill was not used in a row, a cumulative penalty to the check would apply, so if you stop using your longsword entirely in favor of your mace, your skill with the longsword will start to decline while your skill with the mace will increase. Over the course of a couple game days this wouldn't be very much, but after a game week, the skill with the longsword may fall further, and over the course of a few game months where the character never picked up a longsword, he may eventually wield it again and discover his skill has fallen to only half of what it once was.

    This would also have the added benefit of having a TON of skills for the character to learn and increase. 100 different players could create 100 different characters with this, and each of those 100 characters would be quite different from each other depending on which skills the players chose to build upon.

    On the other hand, this would make it more difficult to determine what would challenge the character. A clever algorithm to randomly populate monsters could compare a given monster's combat, spellcasting, thieving and other skills against the character to see if they are a close match, and even matching some monsters to the weaknesses a character has. Build your character up with all combat skills and let magical knowledge be lax and the algorithm may match him up against more spellcasters.
    abachler: "A great programmer never stops optimizing a piece of code until it consists of nothing but preprocessor directives and comments "

  8. #23
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,438
    Those are all good things Jessycat. It certainly a way of doing it, with a few minor repairs here and there. However, I'm aiming for something new or at least more out of the ordinary. Certainly one of the most important factors is to make each character the most unique possible. Many games explore character development in a weak way. You end up playing copycats of previous characters every time you start over.

    Also monsters and NPCs will be "player characters" on their own right. The same rules will apply to them. Having a complex, wide scoped, system will make these also interesting and varied.

    One of the advantages of developing an ascii based game is that I don't need to concern myself with graphics. This is a duh statement. However it also means I can, and should, concentrate myself on other aspects of the game. And definitely for anything RPG-like, character development is a major part of the experience and enjoyment. I should waste here a lot of effort, energy, and even game resources, if it comes to that.

    Anyways... here it is a preliminary approach to the type of attributes system I plan to implement. Skills are another ball altogether for which I don't have a concrete plan yet.

    Attributes

    There are six attributes. Mental and physical attributes are paired, being that for every physical attribute there is a similar mental one.

    Strength - Physical strength or power
    Dexterity - Physical agility
    Constitution - Physical endurance or resistance
    Intelligence - Mental strength and power
    Smartness - Mental agility
    Sanity - Mental endurance or resistance

    Adding to these 6 attributes, there will be two traits
    Balance - How much the physical and the mental attributes are matched. 1 is a perfect balance.
    Valor - How high is the average of the attributes. 20 is the highest.

    Of them Balance is the most important and will have a considerable (although not entirely determining) influence on your character abilities.

    Balance
    I attached a bmp file to this post to help the description of this trait.

    Attributes are represented on the game as a pentagram. Having high attributes is not what one player will try to achieve. The main concern will be to keep them balanced with equal or almost equal scores.

    As you can see from the image, two mirrored triangles define the physical and mental attributes. A circle encompasses them. This circle is drawn between equal scored attributes that are next to each other. Where two attributes have an equal score, and where they are next to each other, an arc of that circle is drawn between them. Your balance increases as the more of the circle is drawn.

    As you can also see from the image, for every physical or mental attribute, its two neighbors are two mental or physical attributes of a different kind (i.e. Strength neighbors are smartness and sanity, not intelligence. Sanity neighbors are Strength and Dexterity, not Constitution).

    Your balance increases, as I said, with equal scores between neighboring attributes. However, this only means the arc between them is at full strength. It also decreases the more of a difference there is between two neighboring attributes that didn't match. Here the arc between them is weak. The weaker it is, the bigger the penalty. So it is possible to have some matches but still have a bad Balance score due to the the unbalanced attributes outweighing the balanced ones.

    A perfect Balance is the one where all attribute scores match.

    All in all, Balance is meant to provide players with a new quirk in which raising attributes is not the main objective, sometimes it is not even the desirable objective.

    Balance is meant to represent some inner self attribute. It will have a strong effect in everything you do. Strong enough to force you to make decisions based on it as far as equipment and raising attributes is concerned. Raising attributes for the sheer fact of becoming a more powerful character becomes secondary. You are more powerful if you have an higher balance.

    Valor
    Valor is less important than Balance, however, we can't deny that having higher attributes should be better than having lower ones. So it's also important to express this even if the consequences may be less important.

    Valor is a simple average of all your attributes. It will also affect everything you do. The higher the valor, the better. However, this trait will have less of an impact on your character abilities, where the attributes score themselves and Balance will call all the shots.

    It will however be one of the most important things when dealing with NPCs. While Balance represents your inner self, Valor is your outer-self. What you irradiate. It's an important trait for first impressions. However mind you, I said one of the most important. Not the most important. Other things will come into play, like certain skills and certain attributes or combination of attributes depending on what the NPC favors most.

    So this is basically a rundown on an yet not perfected attributes system.
    Attached Images Attached Images  
    Last edited by Mario F.; 12-18-2006 at 06:07 AM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  9. #24
    Its hard... But im here swgh's Avatar
    Join Date
    Apr 2005
    Location
    England
    Posts
    1,475
    On a side note, you mention diablo 2 quite a bit and are very interested in how they coded aspects of the game. Is it possible to email the company on any advise? I know they have not released the source code yet ( like id have for doom and quake ) but any helpful advise you can gain from some proffesionals can only make you a stronger coder in the end. Maybe somthing worth considring when you get to the latter stages of your project
    I'm just trying to be a better person - My Name Is Earl

  10. #25
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,438
    I'm especially interested on their object generation system. Nothing else. Much is known about that already. Blizzard has made available much information about how they do it (not the code, but the processes involved). The information is enough to help me with my own ideas.

    The actual formulas and code involved will certainly not be released. Much less to some stranger asking them to incorporate their ideas on his own game. Besides, Diablo II is still very much a reality on battle.net and their object generation system the most wanted secret by players.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  11. #26
    Its hard... But im here swgh's Avatar
    Join Date
    Apr 2005
    Location
    England
    Posts
    1,475
    What gets me is "why" software companys release game code as open source. Isnt it all copyrighted? And if they publicly show their code, surely they leave it open to other skilled people not at all conntected with the company in question to change or alter the code. Saying this, I doubt "all" the source files are released in one hit anyway. This would mean being able to compile and run the applicatoion having the correct software
    I'm just trying to be a better person - My Name Is Earl

  12. #27
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,438
    Software companies may release their code as Open Source for any manner of reasons. All of them are commercial in nature.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  13. #28
    Its hard... But im here swgh's Avatar
    Join Date
    Apr 2005
    Location
    England
    Posts
    1,475
    I see. I was very keen for Psygnosis to release the code Lemmings. But they never did. The core of the game ( so I read ) was coded in C. But I have seen other peoples verisons of the game programmed using Java. Psygnonis were one of my all time favouite gaming companys. Greats like Lemmings, shadow of the beast and speedball made me interested in game creation in the first place
    I'm just trying to be a better person - My Name Is Earl

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. how to split long programe in small files
    By umeshjaviya in forum C Programming
    Replies: 11
    Last Post: 04-15-2008, 02:45 AM
  2. want to make this small program...
    By psycho88 in forum C++ Programming
    Replies: 8
    Last Post: 11-30-2005, 01:05 AM
  3. FILES in WinAPI
    By Garfield in forum Windows Programming
    Replies: 46
    Last Post: 10-02-2003, 06:51 PM
  4. yhatzee, small straight
    By uglyjack in forum C++ Programming
    Replies: 2
    Last Post: 06-13-2002, 03:09 AM
  5. Small app ideas
    By dirkduck in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 02-15-2002, 07:57 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21