• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Norman Barrows

How to time bomb a beta?

80 posts in this topic

 

finding bugs is the coders job. they should not be allowed to sign off on a section of code until it has been thoroughly tested and debugged BY THEM! Then others can have at it.

"Testing can reveal the presence but never the absence of bugs." Even with 100% unit test coverage and round-the-clock QA with a full staff (2 testers to each 1 developer) you still want to plan on your beta testers finding bugs. <3 Because odds are very, very high that they'll hit something weird that you all haven't found yet. That's much of the value of beta testing: a larger volume of monkeys hittin' the keyboard. smile.png

 

Gotta agree with this. All the things you listed (compiler showing all warnings, etc...) are good best practices, and will show any errors in syntax  or scope, but they can't show logic flaws. Code that 'works' perfectly fine, except it doesn't do what you wanted it to, for whatever odd reason. Unless you're saying logic flaws aren't bugs.

0

Share this post


Link to post
Share on other sites

So if you were the programmer of Ocarina of Time you would have fixed all these bugs before the game shipped?

 

I will echo the comment that if the only feedback you get from the game is "it's awesome", you need to find better testers then friends, family, and former players.  There are things wrong with you game and there are design decisions you made that people won't like.  If people are already biased towards your game then they won't mention the little things they think are wrong.  You need some assholes that have never heard of your game to try and rip it apart.  Hopefully this is what you are trying to do with the beta.

 

It may not be a fair comparison, but you game does sound a lot like "Rust" that is in beta on Steam.  Visually, Rust is light years beyond your game (maybe your screenshots are super old so my comparison is off) and is cheaper.

1

Share this post


Link to post
Share on other sites

Hidden RDTSC instruction - Awaits if a debugger is present. Basically is just a hidden windows timer, akin to GetTickCount, but screwed up in the byte code.

 

 

Runtime functions - Use VirtualProtect (or similar for your OS) and implement it. Is a lot of fun and you'll learn a lot.

 

Implement a random obfuscation virtualization environment. Hard, but not as hard as one would perceive. You'll just need to dive into the PE format (agian, for your OS, mine is Windows..), it's honestly quite intriguing.

0

Share this post


Link to post
Share on other sites

So when you say your game is "as big as Skyrim", do you mean the game world is the same size, or does Caveman have as much content in it for the player to do as Skyrim does?

 

 
the game world is 2500x2500 miles in size, and you can walk all the way across it (barring any oceans in the way). you can build rafts and sail across the oceans. and NO LOADSCREENS! all assets are loaded at program start (about 10-20 seconds load time). walk speed is about 4mph. the game runs in realtime (but has accelerated time too!). you have to sleep in caveman, like in the sims, but we'll ignore that for now. so if you walked across the caveman world in reatime without sleeping it would take you 625 hours of real time (26+ days).
 


I believe Daggerfall is the largest commercial RPG ever produced (It would take real life weeks for a character to run from one side of the world to the other - they tested it).
 
Good point. running speed in Caveman is twice walking speed - so, again ignoring the need to sleep, we're at 13+ days (2+ real life weeks @ 24 hours a day) to RUN across the world without using accelerated time, cross country travel, or the teleport playtesting cheat. if you used sprinting in Caveman when not fatigued, it might speed that up a little.
 
 
the game world contains 60,000 caves, which can be unoccupied, or occupied by animals or cavemen.
 
it contains 5000 rockshelters - which are similar to caves, but only found along cliffs.
 
it contains 18,000 huts, which are occupied by cavemen.
 
it contains 20,000 caverns, which are the equivalent of a dungeon level, or a doom level, or a cave level in skyrim. caverns are generated when you enter them the first time,  and saved when you leave. when you return, they are reloaded.   caverns repopulate over time.
 
a new world is generated each time you start a new game - so its random, not hard coded content like skyrim.    the entire world is saved when you save a game, so its persistent.    and you can build and demolish structures, etc, so its modifiable.
 
the game also models changes in terrain and occupants of shelters.  so berries and fruit come and go with the seasons, vegetation coverage can change over time as the climate changes. cave and rock shelters can change occupants from time to time. new huts can spring up, old huts can be abandoned, as the cavemen move on to greener pastures. 
 
so thats how big the world is.
 
how it stacks up in other respects:
 
the game has more than the average number of weapon types - 65  types of weapons - and none are made up. this is partly due to the fact that any tool that can be used as a weapon is considered both a tool and a weapon. 
 
there's no magic in the game, so comparisons in that category can't really be done.  the closest thing to magic in caveman is high quality objects, god artifacts, an god effects.
 
the game includes objects and armor, but in numbers typical for such games (300+, and ~30? respectively).
 
caveman has over 50 types of "monsters" - so far.
 
there are no classes, instead there are skills, 48 or so of them. only 5 or so are weapon skills.
 
you can cook over 30 types of food, and yes there's a cooking skill.  since its a person sim, like the SIMS, food is required, unlike skyrim, where its just a weak powerup in a shooter game.
 
but the place where caveman is REALLY big, is in the actions. like the sims, you can select things and interact with them.  i've never calculated the total number of actions in the game since its so large. i know its over 1000, perhaps as high as 10,000 or more. it has over 100 generic action class handlers, each of which handles an entire class of actions (all repair actions, all cooking actions, etc).
 
by comparison, in skyrim you can open a container, sleep in a bed, open a door, sit, use smelter, use forge, use grindstone, use armor table, use alchemy lab, use arcane enchanter, pull chain / throw lever, and cook. did i forget any?   of course this is not a fair comparison, as skyrim is a quest based rpg shooter with some interactive/open world elements, not a person sim.
 
open world play is another "big" feature of caveman. there are quests, but they are optional.  unlike skyrim, the game is primarily about open world play (think original table top D&D role playing, caveman style), not primarily about completing quests. when i evaluated skyrim, open world play was the first thing i evaluated. i found it to be not-so-great. again, not a fair comparision, as skyrim is designed to be an immersive quest based shooter, and caveman is an open world rpg / person sim.
 
and then there's replayability. Caveman is designed for maximum randomness. nothing is hard coded, everything possible is random. The whole idea is it should be random enough that even i as developer can play and enjoy it without knowing what will happen next in the game. so everything is randomly generated at game start or when you first encounter it (IE cavern level maps).  the game does not use hard coded spawn points, except for occupied caves and shelters. all other encounters and events are random.
 
by contrast, skyrim is entirely hardcoded, same map, same dungeons, same quests, same NPCs - every time you start a new game.  while evaluating it, i created new charcters to test each thing. so i made a fighter for open world play, a dragon slayer, an imperial, a mage, a stormclock, etc.   by the time i was done evaluating it for work, there was little game left for me to enjoy as a fan of the elder scrolls!  sad.png
Edited by Norman Barrows
0

Share this post


Link to post
Share on other sites


"Testing can reveal the presence but never the absence of bugs."

 

true. testing confirms correct implementation. absence of bugs can only be guaranteed by code design, and only under some circumstances.

 

IE:

 

void main()

{

}

 

 

contains no bugs (obviously) - and lets not get nit picky here folks - i think you get what i'm trying to say.

 

its only code that you can't tell by inspection if its bulletproof that you can't design to be 100% bulletproof. then you have to rely on testing or theoretical calculations of edge cases, etc. the sad fact is that its not really possible to path test any code with all possible inputs, if that code is of any significant size. and non-deterministic code makes it even more difficult.

 

and the problem gains an order of magnitude once you get into integration testing. bulletproof by inspection becomes even more difficult. you may be able to account for some cases, but seldom for all.

 

otoh, if you use a systems approach, you can break down systems into subsystems until they can be made relatively bulletproof (bullet resistant? <g>).   Then you can build up systems in a bulletproof manner. this tends to minimize bugs of all types getting through.

 

bugs are inevitable because hardware and software are made by humans.

0

Share this post


Link to post
Share on other sites


So if you were the programmer of Ocarina of Time you would have fixed all these bugs before the game shipped?

 

absolutely! assuming i could find them. when building a complex system like that where every bit interacts with all the rest, you have to take into account the ramifications of their being combined. the more bits you add, the more connections possible, and the more you have to account for. not thinking through all the possible the effects of a feature results in stuff like random town encounters with vampires, cultists, and thieves killing all the merchants in Skyrim - rendering it eventually unplayable. there they had a spawn point level based design, and added random encounters that could kill off required NPCs. so they modeled random encounters that can kill npc merchants, but they didn't model killed merchants getting replaced by new npc merchants - which is required for a balanced simulation that will run correctly long term. in fact i don't think anyone gets replaced if they're killed in skyrim, except guards and dark brotherhood followers, and i'm not sure about the dark brotherhood followers, never lost one.  i lay the stripped dead bodies of the merchants in the middle of the street out on display.  as a persistent corpse, they can be used as safe containers that don't repop.

Edited by Norman Barrows
0

Share this post


Link to post
Share on other sites

It may not be a fair comparison, but you game does sound a lot like "Rust" that is in beta on Steam.  Visually, Rust is light years beyond your game (maybe your screenshots are super old so my comparison is off) and is cheaper.
 

 

it seems the only things in common are that some parts of rust have a paleo-type setting.

 

rust is a mmo about survival and crafting. it seems to start paleolithic, but goes beyond that apparently. the developers themselves say they're not sure where they'll go with the game.  nice rocks though! i'll have to do something like that.

 

caveman is a simulator. like a flight sim, or a sub sim, or any other full tilt hard core vehicle simulation software. only difference, you're driving a caveman. so its all about simulation realism first, and pretty but unrealistic graphics second. in fact, the game was designed specifically that way. most game devs seem to pick a graphics engine, then build what game they can with the remaining clock cycles. caveman is done the other way. you build the game, and what clock cycles are left, you draw everything as good as you can. an example: caveman uses rigid body animation for monster and npcs, allowing more monsters and npcs onscreen at once. its doubtful that today's hardware could run it if it used traditional skeleton and mesh deformation models.  can games draw over 100 npcs onscreen at once with mesh deformation and no slow downs?   the most i've ever seen in skyrim is about 20-30 in the rebellion campaign battles. and the bodies disappear as soon as you kill them! if you're quick, you can loot them first.    ; )

 

graphics in caveman are designed to attempt to mimic real life terrain. as such, plant and tree density is much higher than most games. so instead of going for woods effect with a few trees, caveman attempts to draw true dense woods. requirements of the simulation can also dictate how graphics are done. caveman requires sky and cloud graphics that can be driven by the weather engine. also, it has to run on a single low end pc - both the simulation, and the graphics. the graphics still have a long way to go in many respects.  but i'm only one guy, and i know where i can, and cannot compete. a graphics arms race can only be won by the dominant player in the market.   also, graphics don't make a game, just look at minecraft.     

Edited by Norman Barrows
0

Share this post


Link to post
Share on other sites


Code that 'works' perfectly fine, except it doesn't do what you wanted it to, for whatever odd reason. Unless you're saying logic flaws aren't bugs.

 

first you write it, then compile it, then run it and test it to make sure it works as intended. this eliminates logic flaws - but only in that bit of code. there's still integration errors to deal with, when you hook up two or more good pieces of  code incorrectly. and then sometimes there's odd ball edge cases that nobody ever thought of.

0

Share this post


Link to post
Share on other sites


Hidden RDTSC instruction

 

no good: false positives if they alt tab away - correct?

 

i have high rez timers on the game loop i could query for excessive frame time (indicating debugging actions going on), but same difference, false positives from alt-tab.

 

i think there are other way's to detect a debugger. haven't finished reading all the links i saved on the subject. i plan to do a posting to my gamedev info journal, but there's a TON of info!

0

Share this post


Link to post
Share on other sites


Runtime functions - Use VirtualProtect (or similar for your OS) and implement it. Is a lot of fun and you'll learn a lot.

 

 

so you DL some code to the client, and use:

 

BOOL WINAPI VirtualProtect() to set PAGE_EXECUTE ?

 

but they could still get a memory dump, couldn't they? then make their own code?

0

Share this post


Link to post
Share on other sites

So if you were the programmer of Ocarina of Time you would have fixed all these bugs before the game shipped?

absolutely! assuming i could find them.

That assumption, right there, is really not a safe one. No offense, but even the best designed code with zero warnings vs. -Wall is still going to run into unforeseen logic errors...and the more complex the code, the larger the code base, the higher those odds. I doubt that your code is all so trivial as an empty main function. smile.png

(But, if you really do have a full proof way...you're in the wrong line of work. Software Hardening and Static/Dynamic Taint Analysis are both very vibrant fields of research; they could use you. Not to mention how every single other software package in the wild right now experiences bugs for the first several years of their life time in consumer hands.) Edited by thade
0

Share this post


Link to post
Share on other sites

 


So if you were the programmer of Ocarina of Time you would have fixed all these bugs before the game shipped?

 

absolutely! assuming i could find them.

 

In a perfect world, sure -- but in reality that's not the way it works. Games ship with unknown and known bugs all the time. Like you, the engineers who take pride in their work don't like it, but can't press back on the publisher when they come in and say "Hey guys, you can't let the schedule slip over 20 known bugs that only 1 in 10000 people will be adversely affected by." I've got no love for slave-driving publishers, and I think that often its their own policies and practices that end up putting themselves and their studios in a hard place, but you really can't miss that holiday launch window if you were relying on it -- people will lose their jobs if you do, usually starting with the people at the bottom.

 

In your situation, perhaps you aren't relying on that window and you don't have anyone but yourself to answer to or worry about affecting, but as soon as you have a publisher to please, a marketing budget, or an employee who's not a partner in the company, the game changes. 

1

Share this post


Link to post
Share on other sites


Implement a random obfuscation virtualization environment.

 

already done.

 

there is one in the game exe that does both game related and DRM related tasks,. it uses code generated on the fly, self modifying code, and encrypted code. all programs are written in its proprietary machine language. you write one line of assembly as a comment, followed by usually three lines of machine code to implement the one line of assembly.

 

there is a second separate stand alone vm that decrypts and runs the game exe, as well as running its own proprietary vm programs in general. it has its own proprietary architecture, instruction set, .programming language, compiler, p-code language, and vm runtime. programs to encrypt a game exe and decrypt and run a game exe are just two example programs written for the stand alone VM. the VM was made BEFORE the game, just for copy protection purposes. no sense making a game for profit if you can't protect it. this vm is much more sophisticated. i've actually written direct3d fullscreen test apps with it that run at 62.5 fps.

 

i look forward to the day when PC's are fast enough to just write a vm, then write the game in the vm's language - eliminating the dreaded release build delay from the development iteration loop.  until then, i use a macro processor to generate c++ code from a high level, low keystroke scripting language. saves on typing, like a custom vm language can, but doesn't help with release build times.

 

however, as pointed out by ApochPiQ, VMs are not impervious to attacks:

 

from:

http://www.gamedev.net/topic/654995-checksum-crc-md5-hash-check-game-code-in-ram/

 


The VM concept may seem like a solid approach, but you have a critical flaw in your architecture.

An observant reverse engineer will notice within seconds of viewing your program's import table that you use a select few "interesting" API functions. Encrypted code is not a surprise to anyone in the reversing field; even "innocuous" things like packers have been around for ages, and most reversers know how to get past them.

If I were, hypothetically, to take a look at your program, this is how my thought process as an experienced reverse engineer would look:
Hmm, weird set of APIs. Also if I break the game execution at random times I end up in this weird call stack.
Let's see what this code does... oh, it's a VM.
Hey look! It's running encrypted code!
Let's find all the places that decrypt input code and hook them...
... aaaand shunt over to a dummy VM implementation in an injected DLL (or monkey-patched binary if I feel brave)
Lookit that, I can dump all the raw VM bytecode now
It's a trivial VM, so figuring out what each bytecode package does is just another reversing exercise
Wow, some of these look like they are game-critical...
But these ones don't! I found your DRM!
Surely there is some recognizable pattern to what opcodes or general code pattern is followed by DRM code versus game logic...
Little analysis later, some shunting back of the VM decrypt process, and poof...
And now I have a crack for your game.

A good reverser could pull this off in a long day of work; a mediocre one could do it in a week.


Unless you expect that buying yourself 24 hours of "safety" will be the difference between commercial success and commercial failure, you're wasting your time.

 

software seems to need two types of protection:

 

1. copy protection to prevent illegal distribution having a negative effect on legit sales.

 

2. anti-crack protection for the copy protection.

 

also, any game that has artificial built in limits that can be cracked (such as only play for free to level 20) needs anti-crack protection.

 

i've gotten exe checksum with no checksum in the exe and ram checksums working for anti-crack, and expiration date not based on system clock for DRM working.

 

i've been able to hide string constants, and pepper the code with tons of system calls to drastically increase the number of references to suspicious systems calls such as GetSystemTime. 

 

one big thing i've done relates to the following quote:

 

"they can't hack what ain't there!"

 

so to the greatest extent possible i've used #ifdef DEMO and dead code elimination to completely remove full version code from the demo. in some cases i've had to write custom code for the demo, such as a generate_demo_map() routine.

 

but getting back to the ET phone home....

 

so the server sends some VM p-code to the client. the client runs it. the client doesn't store it on disk. the server must send vm code every time the game wants to run.

 

the packets could be intercepted and the p-code gotten at that way. a dummy client could be written that gets the p-code and saves it to disk. a ram spy tool could get the p-code from ram. and the cracker has the client exe , so they have the vm code. once they reverse engineer the VM, and get the p-code somehow, its just matter of time. needless to say, all of this is a bit easier said than done. but still do-able.  

 

all these types of attacks would need anti-crack protection.

 

doing a google on your three suggestions turned up a bunch of useful stuff for a search on "random obfuscation virtualization environment".

 

i'll be posting all the links i found in my gamedev info journal here as soon as i get a chance to sift through it all, and at least provide a couple words for each link about what the info is about.

 

so it a two front war:

1. don't copy me illegally - copy protection.

2. don't crack the code that provides copy protection - anti-crack protection.  

 

note that sometimes its not illegal copying, its time limits, cheating in multiplayer online games, etc. that you want to make tamper resistant.

0

Share this post


Link to post
Share on other sites

 


Runtime functions - Use VirtualProtect (or similar for your OS) and implement it. Is a lot of fun and you'll learn a lot.

 

 

so you DL some code to the client, and use:

 

BOOL WINAPI VirtualProtect() to set PAGE_EXECUTE ?

 

but they could still get a memory dump, couldn't they? then make their own code?

 

 

That really sums up the point we were getting at earlier: There is no perfect solution that can be isolated on the users machine -- you need a a trusted machine, or in a distributed system a quorum of neutral third parties, to have any semblance of security. A dedicated attacker will always be able to go one step further on their own turf. And lets not forget that their job is far, far easier than yours in this arena -- you must unfailingly block every attack -- they just have to wait for you to fail to do so one time. In the example above, lets say that you could prevent them from dumping memory -- sounds good, but a truly dedicated attacker could cool the physical memory, pull it from the system, and then probe it to read out your code. This is a known attack vector in high-end reverse-engineering efforts. Is it likely that a cracker will go to this extent to make your $20 cult hit free to the masses? Not likely, but it illustrates just the same that no matter how far you can go, it just isn't far enough to be perfect.

 

This is the reality you have to accept if you can't enforce security in a connected fashion. You can make a cracker work harder, but you can never make it impossible for them to win in the end. Many small teams have had success by marketing their lack of DRM as a feature, others have found creative ways to cajole pirates into paying up, others have found new monetization models that aren't deflated by piracy. No one has found a fool-proof way to stop pirates dead in their tracks.

 

On a further note -- if all this concern, at least early on, is about people being able to pirate and distribute your Beta -- what would be so bad about requiring your beta participants to connect to a server to validate? You wouldn't need to carry that policy forward for paying customers. Requiring an internet connection might possibly skew your beta feedback, but that's probably an acceptable tradeoff unless your target market is the rural farming set.

1

Share this post


Link to post
Share on other sites


That assumption, right there, is really not a safe one. No offense, but even the best designed code with zero warnings vs. -Wall is still going to run into unforeseen logic errors...and the more complex the code, the larger the code base, the higher those odds. I doubt that your code is all so trivial as an empty main function.

 

i totally agree. thats why i said "assuming i could find them".  odds are in that title, they had a base engine, then kept adding more custom stuff to it. eventually almost every item becomes a special case with its own behavior and code. such "evolution" of the code is ok, but can lead to glitches down the road as things become bigger and more complex. its better to try to figure out a framework or system for the different things first, so undesirable interactions are easier to predict. 

 


(But, if you really do have a full proof way...

 

unfortunately no. rigorous attention to detail and testing has allowed be to release games in the past with very few errors, and never with a major one. then again, apparently i'm the "judge /  perfectionist" personality type when i'm on the clock (and the "happy hedonist" personality type when off the clock! <g>). typos in string constants are another thing though, there's no spell cheker in my IDE! <g>.

0

Share this post


Link to post
Share on other sites


In your situation, perhaps you aren't relying on that window and you don't have anyone but yourself to answer to or worry about affecting, but as soon as you have a publisher to please, a marketing budget, or an employee who's not a partner in the company, the game changes. 

 

yes, i guess i'm blessed in the fact that i'm the developer, publisher, and financial backer. so all three are of like mind and one goal.

 

as a fan of the game, i know what needs to be done - hopefully - can't think of everything. this is where other playtesters help.

 

as the dev, hopefully i know how to do it, or can figure it out.

 

as a pub, i have the good sense to listen to the devs and not push half finished crap out the door. my job is marketing and sale fulfillment, not design, development, or project management. as a pub, i never forget i'm really nothing but a glorified car salesman - i don't build them, i just try to get you to buy them. 

 

and as backer i have the wisdom to sit back and let my people do their thing, after all that's why i bet on them in the first place.

 

i've never really timed my releases around the holidays etc. i release when its ready. but i have found that releases made in summer and after the holidays do quit well. probably because they are released when there's little in the was of new AAA titles to compete for attention. summer releases get the user's dollars before the xmas AAA onslaught, and after xmas releases get the after xmas sales when users buy what they didn't get for xmas, or after they've finished the games they got for xmas.

 

. i did release caveman v1.x during september/october 2000. so it was hitting the radar about xmas time. NBC evening news in Washington DC picked it up as a last minute xmas gift idea. got so many hits, it crashed by website. took a week to get back up again, as i was going through a local mom and pop webhosting reseller who was closed for xmas.

 

Caveman will be released when ready, perhaps a couple months from now. but there's still so much to do, i may have to release a version 3.0 and immediately begin on version 3.1 to get it all in there - stuff like the "bring on the dinos!" option. <g>.

 

cavemen with javelins and knives vs wolley mammoths is already a sight to see, i can only imagine what it would be like vs t-rex! actually i don't have to. t-rex is one of the animals implemented in the game already but not used. but i can trigger a t-rex encounter from the playtest menu.   cool! i'm going to have to try that!  and post screen shots! <g>.  a little preview of the "bring on the dinos!" option.

0

Share this post


Link to post
Share on other sites


On a further note -- if all this concern, at least early on, is about people being able to pirate and distribute your Beta

 

actually, i got all that drm and anti crack stuff working, then tuned it off in the demo and beta! <g>.

 

you can email me right now and get a link to the beta demo with nothing more than watermarks, an unprotected expiration date, and an unprotected 30 gameday limit.

even cracking all that, they'd only get a game with a 100x100 mile world, with no load or save, and many other high end features missing. only the watermarks, nag screens,  30 gameday limit, and beta expiration date are crack-able. nothing else can be cracked - "cause it ain't there!".  thank god for  #fidef DEMO, and especially dead code elimination and link time code generation (that's the one that only links code actually called, right?).

 

i've even considered releasing the game in a "Caveman III, version 0.x" format for free. this approach is popular with indie games under development. they give away what they have while under development, eventually evolving their code base into a stable release version 1.0, which they then sell.  sort of a long term open beta.  

 

but caveman may be too close to release for this.

 

as it stands now, the complete version makes for quite a game that would take a LONG time to play.

 

unlike most rpgs, you can have more than one player character (band member) under your control - like household members in the sims. you can tab between band members at any time. you can have up to 10 band members in your band. you can recruit new band members at any time you have less than 10 band members. and the game doesn't end until the last band member dies. so the original band member, the character you created when you started a new game, might die, but the game continues with the remaining band members, who can then recruit a new band member to replace the dead founding band member. so the game could theoretically go on forever - despite the fact that back ground radiation modeling (IE old age) will eventually kill off individual members of the band from time to time. band members may die, but the band lives on.

 

so its a pretty big game already, despite the fact that i have yet to finish the quest generator, raiding and inter-band rivalry, mating and offspring, modern animal types, aquatic animal types, "bring on the dinos!" etc. 

 

 

 

 

 
 
 
fn v demo_intro_screen
i y dy
= y 100
= dy 25
c Zbeginscene
c Zclearscreen 0 0 0
c Zbeginsprite
c tx2 400  y "This is a playable demo version of Caveman 3.0."
 
c tx2 400 y+dy*2  "Limitations of this demo:"
c tx2 400 y+dy*3  "1. A 100x100 mile game world."
c tx2 400 y+dy*4  "2. The same hard coded game world every time you play."
c tx2 400 y+dy*5  "3. Only 4 types of animals."
c tx2 400 y+dy*6  "4. Encounter types chosen totally at random."
c tx2 400 y+dy*7  "5. No quest generator or quests."
c tx2 400 y+dy*8  "6. No tools, editors, or testing cheats like teleport, kill all "
c tx2 400 y+dy*9  "   hostiles, recharge all stats, or view unexplored map."
c tx2 400 y+dy*10 "7. No load game, save game, or autosave."
c tx2 400 y+dy*11 "8. You can only play for 30 game days."
c tx2 400 y+dy*12 "9. No hiring warriors to fight for you."
c tx2 400 y+dy*13 "10. No friendly NPCs as traveling companions."
c tx2 400 y+dy*14 "11. No getting your travelling companions to join your band."
c tx2 400 y+dy*15 "12. No God artifacts. - Hey, whats an rpg without artifacts, right?"
c tx2 400 y+dy*16 "13. No high quality objects. - the Caveman equivalent of magic items"
c tx2 400 y+dy*17 "14. No Caverns: dungeon adventuring - caveman style!"
c tx2 400 y+dy*18 "For more information on the full version, visit:"
c tx2 400 y+dy*19 "https://sites.google.com/site/rocklandsoftware/"
 
c tx2 400 y+dy*21 "Click to continue..."
c Zendsprite
c showscene
nb 
p
nb
 
 
 
c Zbeginscene
c Zclearscreen 0 0 0
c Zbeginsprite
c tx2 400  y "This is a playable demo version of Caveman 3.0."
 
c tx2 400 y+dy*2  "Features only available in the full version:"
c tx2 400 y+dy*3  "1. A 2500x2500 mile game world."
c tx2 400 y+dy*4  "2. A randomly generated true world with islands, mountain chains,"
c tx2 400 y+dy*5  "   forested areas, deserts, jungles, tropical savannas, etc. All"
c tx2 400 y+dy*6  "   terrain types are included."
c tx2 400 y+dy*7  "3. A completely new randomly generated world every time you start"
c tx2 400 y+dy*8  "   a new game."
c tx2 400 y+dy*9  "4. Over 50 types of actual extinct Mega-fauna to hunt or be hunted by!"
c tx2 400 y+dy*10 "5. Encounter types based on terrain type and animal frequency."
c tx2 400 y+dy*11 "6. Quest generator and quests."
c tx2 400 y+dy*12 "7. Tools, editors, and testing cheats like teleport, kill all "
c tx2 400 y+dy*13 "   hostiles, recharge all stats, and view unexplored map."
c tx2 400 y+dy*14 "8. Load games, save games, and autosave."
c tx2 400 y+dy*15 "9. No time limit. The game ends when your last bandmember dies."
c tx2 400 y+dy*16 "10. Hire warriors to fight for you."
c tx2 400 y+dy*17 "11. Friendly NPCs as traveling companions."
c tx2 400 y+dy*18 "12. Get your travelling companions to join your band."
c tx2 400 y+dy*19 "13. God artifacts. - Hey, whats an rpg without artifacts, right?"
c tx2 400 y+dy*20 "14. High quality objects. - the Caveman equivalent of magic items."
c tx2 400 y+dy*21 "15. Caverns: dungeon adventuring - caveman style!"
c tx2 400 y+dy*22 "16. No demo nag screens, 'feature unavailable in demo' messages,"
c tx2 400 y+dy*23 "    or demo watermarks."
c tx2 400 y+dy*24 "For more information on the full version, visit:"
c tx2 400 y+dy*25 "https://sites.google.com/site/rocklandsoftware/"
 
c tx2 400 y+dy*27 "Click to continue..."
c Zendsprite
c showscene
nb 
p
nb
.
 
 
 
0

Share this post


Link to post
Share on other sites


lets say that you could prevent them from dumping memory -- sounds good, but a truly dedicated attacker could cool the physical memory, pull it from the system, and then probe it to read out your code. This is a known attack vector in high-end reverse-engineering efforts. Is it likely that a cracker will go to this extent to make your $20 cult hit free to the masses? Not likely, but it illustrates just the same that no matter how far you can go, it just isn't far enough to be perfect.

 

drm anti-crack protection is not a battle to be won. the objective of stopping cracking entirely is almost impossible - with trusted machine (and user) perhaps the only way - like the special PCs we had at wright pat air force base for classified data.  

 

instead, drm is a delaying tactic. the objective is to make it more hassle than its worth. 

 

and as you say its unlikely a cracker will go to extraordinary lengths to crack my $20 cult hit. i'm sort of counting on it in fact. the old version that got cracked has zero anti-crack protection, and was a textbook case of the simplest code to crack - find string constant, then modify nearby jmp instruction, done!

 

so the plan is to only put drm and anti-crack in the full version. no need to give them an advance look at the code in a demo or beta. they'll have to buy or get the game from a legit user to crack the full version.

 

and the full version will  strive to make the ratio of "glory to be gained by the cracking" vs "hassle involved in the cracking" so unfavorable that no one goes to the effort.

 

if i were a big AAA game, the glory would be much greater. sometimes its nice to be the little guy.

0

Share this post


Link to post
Share on other sites

 

the game world contains 60,000 caves, which can be unoccupied, or occupied by animals or cavemen.

it contains 5000 rockshelters - which are similar to caves, but only found along cliffs.

it contains 18,000 huts, which are occupied by cavemen.

it contains 20,000 caverns, which are the equivalent of a dungeon level, or a doom level, or a cave level in skyrim. caverns are generated when you enter them the first time, and saved when you leave. when you return, they are reloaded. caverns repopulate over time.

a new world is generated each time you start a new game - so its random, not hard coded content like skyrim. the entire world is saved when you save a game, so its persistent. and you can build and demolish structures, etc, so its modifiable.

TBH, this sounds to me like a game world around a hundred times bigger than it needs to be.  How many players are going to go through 20,000 caverns without starting a new game? If that's the measure of the size of game, then Torchlight (and FATE) are even bigger since they have 'infinite' dungeon levels (or close enough anyway). Saying your game is 'as big as Skyrim' is a poor comparison, since a game like Skyrim is measured in terms of content, not how far you can run before you hit the edge of the world.

 

I hope you're right and your game isn't cracked - but I also hope that your game is fun to play (some games aren't cracked because no one wants to play them...).

 

Btw, it also sound like a game where the performance is going to keep dropping the longer you play. In the beginning nothing is generated, so the system resources needed are scant. After a few thousand caverns have been formed though, will the game still be able to run as fast and smooth? Something for your beta testers to look into - maybe include a 'generate caverns' cheat, so they can test the game with more and more caverns and caves and shelters being stored.

Edited by Mouser9169
0

Share this post


Link to post
Share on other sites


Saying your game is 'as big as Skyrim' is a poor comparison, since a game like Skyrim is measured in terms of content, not how far you can run before you hit the edge of the world.

 

then its not as big as skyrim, athough measured in content it might well be as well. dunno, don't really care. i pretty much used up skyrim in about 2 months of heavy play. i didn't even get close to using up caveman v1.x in 3 years of long term playtesting. but then again its designed that way, to be a continuous paleo-world simulation that will run forever.

 

frankly, i'm not interested in whether to do it, or who does it and who doesn't, or how many copies they sold without it. i'm interested in technical info on howto. THAT is the topic at hand. other posts strike me as being off topic, though some may see "whether to or not" as a more fundamental question to be answered first. if you have a suggestion for a drm free way of selling the title in question that will work pretty much for sure, given a title with a proven track record, please share.

 

you seem to know a lot about torchlight, is there a cracked version ?  (make that freely downloadable - it doesn't have drm). they might make a good case study of how to do it drm free. $15 price point, diablo clone, steam and direct web sales, correct?  did they do a pre v1.0 release or large public beta to build a fan base first?

0

Share this post


Link to post
Share on other sites

but I also hope that your game is fun to play (some games aren't cracked because no one wants to play them...).

 

well this game has made the network evening news before (NBC, Washington DC, last minute xmas gift ideas, Dec 2000), and has been cracked before. 

 

 

as for fun, you're welcome to see for yourself. shoot me an email at rocklandsoftware at gmail dot com, and i'll send you the links to download the beta of the demo.

 

the full game is only a 52 meg DL.  the demo is the same, with a demo exe file.

Edited by Norman Barrows
0

Share this post


Link to post
Share on other sites


Btw, it also sound like a game where the performance is going to keep dropping the longer you play. In the beginning nothing is generated, so the system resources needed are scant. After a few thousand caverns have been formed though, will the game still be able to run as fast and smooth? Something for your beta testers to look into - maybe include a 'generate caverns' cheat, so they can test the game with more and more caverns and caves and shelters being stored.

 

not a problem. all caverns are single levels for the moment, and loaded when you enter, and saved when you leave, just like a level based shooter engine. load and save times are split second short. so caverns of unlimited size are easy, just add connections between levels, and generate deeper levels as needed. the only limitation is hard drive space. all systems in the game are designed that way. they aren't linked lists of objects that degrade the bigger they get. in fact, no linked lists or objects at all. just fast non-OO procedural C++, PODs (plain old data types), and ADT code organization with global access in the api's exclusively for get and set methods.  speed and performance over style. heap is only used to allocate a 2 meg buffer to check a savegame's checksum (corrupt file check), and only for about 5 lines of code with no branching before its freed. pretty much all data structures are static and appear in the data segment. static is not an issue since the required sizes are know at compile time.

0

Share this post


Link to post
Share on other sites


you seem to know a lot about torchlight, is there a cracked version ? (make that freely downloadable - it doesn't have drm). they might make a good case study of how to do it drm free. $15 price point, diablo clone, steam and direct web sales, correct? did they do a pre v1.0 release or large public beta to build a fan base first?

 

There's not a 'cracked' version because retail (physical copy available through their website as well as being out on store shelves - nice box, raised lettering, etc...) was DRM free from the start. There may be a 'no-steam' .exe floating around, if one hasn't been officially released.

 

Runic Games had the 'Blizzard' advantage when it came to fan base. You had star developers from the original Diablo/Diablo II team (Blizzard North) joining up with the creator of FATE, and the team from Mythos. For people into the action-adventure, dungeon crawling, let's go kill things then go shopping genre this was an absolute dream team. So there was a lot of 'hype' and publicity about the game just from that factor alone. By the time the game came out, most of it's target audience was ready for it. I'm not sure how they handled the beta for Torchlight - I do know they listened to the feedback and worked from it, in a few documented cases having fixes for bugs reported in the forums up within hours, so there was a 'connection' between the team and the community (as opposed to companies who run test servers, collect feedback, then cheerfully ignore all of it and ship 'as is').

 

It came out at $20 Steam and Retail, and held that price point for quite a while before dropping, then held at $15 for another long bit. I don't know whether it's because twenty dollars is the largest bill most Americans keep in their wallet, or some other reason, but that seems to be the magic 'dividing line' between the 'casual' games and the longer (and presumably better) ones. A casual might start at $20 through some small portals, and maybe an initial run in Walmart (HER Interactive does this with the Nancy Drew series), but the price drops to $6.99 pretty quickly (within a few months) or else the game becomes part of a 'bundle' pack. On the other extreme you have Skyrim, which stayed at $60 even with the complete Elder Scrolls Anthology, which included Skyrim and all its expansions/DLC along with Oblivion and Morrowind with all their expansions/DLC plus Arena and Daggerfall for only ten dollars more on the same shelf.

 

Torchlight was moddable, with the editor released soon after the game (my retail copy had it in already I think... maybe I downloaded it). This was also the time where there was a lot of backlash against Ubisoft and the 'always on' DRM schemes where you got booted from your single player game if your internet connection went down for a few minutes, so I'm sure some people bought it to make a statement.

 

Ultimately, I think it was successful DRM free because it targeted a game playing demographic where people buy games. Between Steam and being on store shelves, it was easier to buy it legitimately than it would have been to go searching for a torrent and downloading it that way (with all the risks that go along with that). Yes, the Steam version had Steam DRM - but there was always the retail option available, so it really was a choice for consumers.

 

The best case study for DRM free games is Good Old Games. When they started, they just had 'older' titles reworked to run on modern OS's. As time went on and the model proved profitable, more and more games started moving there. While the bulk of their catalog is still 'old school' games, they do have a growing number of fresh releases as well.

 

I'll shoot you an email. I can't commit to being a full on tester, but I'd love to see what you've got, and I'll give you what feedback I can.

Caveman sounds interesting if nothing else - a change from the same scripted formulas that get churned out over and over and over...

0

Share this post


Link to post
Share on other sites


There's not a 'cracked' version because retail (physical copy available through their website as well as being out on store shelves - nice box, raised lettering, etc...) was DRM free from the start. There may be a 'no-steam' .exe floating around, if one hasn't been officially released.

 

if its popular and drm free (or even if its not drm free) odds are there's a free version somewhere. have you looked? want to bet a dollar on it? <g> (just kidding)

0

Share this post


Link to post
Share on other sites

Runic Games had the 'Blizzard' advantage when it came to fan base.

 

well that explains the popularity.

 

you don't want to SELL games to users, you want them to SUBCRIBE to your game as life long fans. not subscription as a sales model technically, but in essence.

 

in this case, they simply made the next game in the series that all those fans subscribe to. so it was under a different studio name with a different lineup in the dev team. who cares? its still diablo! and with a BETTER team building it! any diablo fan would definitely be buying that sucker when it came out. and there are a LOT of diablo fans.

Edited by Norman Barrows
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0