Jump to content

  • Log In with Google      Sign In   
  • Create Account

Gamedev info


Game Design Patterns: Elements of Reusable Game Software

Posted by , 07 September 2013 - - - - - - · 1,169 views
game design patterns
Game Design Patterns: Elements of Reusable Game Software

Patterns. Seems to be all you hear these days, right? What is this pattern? Should i use it? Is this code an example of pattern A or pattern B?

It appears that "Patterns" came about due to the discovery of recurring themes in the organization of objects in OO languages for specific tasks.

Sounds like just the thing an OO developer could use right?

Only thing is, i have yet to hear of a pattern that comes from games. Granted, i hear of many patterns that are applicable to the implementation of some subsystem of a game. And where such cases occur, i see no reason not to use traditional non-game software development patterns.

But when you start applying patterns for the overall design of non-realtime business apps to realtime games, you're heading into round peg square hole territory. The fit may not be that great.

So, everyone else has their patterns, business app development, enterprise development, etc. Why not game development?

after all, games are modeling and simulation software, which, if you've ever taken software engineering, you know is a rather different sort of a beast from all other types of apps.

so if games are a fundamentally different type of software, why use patterns from software that's fundamentally different from games?

for sub systems that are similar - sure. but for games, which are fundamentally different than the software the pattern comes from?

So what is a pattern anyway?

Well, apparently its a recurring theme of object organization for a given task.

All fine and good, but not all games are OO. And non-OO design alternatives such a component-entity systems are popular.

So can we make a more general statement about game design patterns?

an object is a hunk of data, and the functions that use it. technically, its a specific type of implementation of an ADT, an Abstract Data Type.

in fact, " a hunk of data, and the functions that use it " IS the definition of an abstract data type.

so patterns are a recurring theme of how to organize data and code for a given task.

Well, hey, there's LOTS of recurring themes of how to organize code and data for a given task in games! Sounds like games have their OWN patterns!

What might some of these patterns be?

Well, to the experienced gamedev, they'll be so patently obvious as to not even be considered a "pattern".

The very first pattern one sees in games is the "init - run - uninit" pattern.

its a common recurring theme of a way to startup, use, and shut something down, such as the game program, an individual game, or a mission.

ok, super simple and pretty lame eh? well, hey, i didn't say games had COMPLEX patterns!

second pattern that comes to mind is the "main game loop" pattern.

you see this pattern in just about every game. its a recurring theme of a way to repeatedly process input, update the game world, and render the scene.

i know, still pretty lame, but hey- its a pattern!

so what are some other recurring "patterns" in games?

entity lists
entity type definitions
a world or level map
a sound library
a graphics library
graphics specific things like render queues, scene graphics, trees, etc. now we're getting into the game parts that are more like non-game "patterns". IE its all about the TASK. a tree won't work when you need a state manager, and vica versa.
now there's an area that someone should do an article on, when to use such "game patterns".

but for each of these things one can go through and describe it as a pattern:

the entities list pattern:
entities are stored in a list. functions like render and update operate on the list.

one could also get into implementation, although that's technically beyond patterns:
entity lists are typically implemented as a vector, std list, array of structs, or component entity system.

but note that a component entity system is also a "game design pattern" -. perhaps one of the few "real" ones we have. its a recurring theme of how to organize code and data for one of two possible tasks: soft coded entity type definitions -or- last ditch optimization of update once render can go no faster and you still aren't fast enough. C-E for optimization is not a common pattern. C-E for soft-coded entity type definitions is the normal reason for C-E. And C-E has no hard defined implementation method, just like a "pattern".

So odds are there are many things like a "C-E system pattern" in games.

As i think of more, i'll add them here.

If anyone else thinks of some, please leave a comment!

already i have a bunch popping into my head:
pickray
mouse-aimed camera
heightmap
"move all, check all" collision algorithm
"move and check each in turn" collision algorithm
stepped movement
ray casting
A*


the list goes on....


maybe i should write a book! Naw, screw that! i'm too busy building games! <g>


A checklist for adding a new variable to a program

Posted by , 05 September 2013 - - - - - - · 818 views

A checklist for adding a new variable to a program

We're programmer's. We code. We spend our time implementing stuff - making it do this, or making it do that.

Well, one of the first things we need when beginning the implementation of a new feature is variables.

So we spend a lot of time declaring and implementing variables. So much time, that i have memorized a "checklist" of the steps involved.

By following the checklist for each variable required, you're pretty much guaranteed a complete implementation for a given feature, with no parts forgotten. Posted Image

The checklist is so useful that sometimes i'll think of a new feature, come up with a few new variables i need, go through the checklist, and i'm done - feature implemented! Posted Image

since you do this for each variable, you might say its a "data driven" way to go about it! <g> (hey, i had to use at least ONE cool term somewhere, right?). Posted Image


so now, without further adieu, here's the checklist:

When you add a variable to a program, you have to:

1. declare it (unless you use one of those cool weirdo languages <g> )
2. initialize it
3. load it (optional)
4. save it (optional)
5. change it. usually via user input somehow. sometimes by other internal game systems. if it never changed it would be a constant! Posted Image
6. use it. use it to do something in the game. make it do something - have some effect. i mean - that's why you declared it right? so you could use it! hey - i need that to do cool stuff! Posted Image
7. display (optional). some variables need to be displayed, some don't.
8. un-initialize. some variables need to have memory de-allocated, etc. (boy this spell checker can't spell any programming terms can it? <g> Posted Image )



i memorize it as:

declare-init-load-save-change-use-display-uninit



So there it is, the infamous checklist. Like i said, i find that if you go through and write all those bits of code, you're usually done implementing a variable. As always with game development, the usual caveats apply. there are no absolutes. surely somewhere at some time someone will make a game that requires something additional. But i've been using the first 6 on the list for over 20 years, and the last two just occurred to me while adding a gamespeed variable to Armies of Steel II.

Happy coding ! Posted Image



handling lost devices

Posted by , 04 September 2013 - - - - - - · 701 views

DX9 Lost Device Example

I decided to implement Alt-tab in my project, and went looking for info on handling
lost devices. The DirectX docs were their usual disappointment. Eventually a serach
of Gamedev and the Web found all the bits an pieces needed, but not in one place.
So I decided to post what I'd found for use by others.

First, you'll want to make sure you load all non-dynamic resources into managed memory pool,
not default. This essentially keep a backup copy of resources in regular ram that D3D can use
to automtically restore vidram as needed.



Here's the basic algo:

result=Present();
if (result == D3DERR_DEVICELOST) do_lost_device();



do_lost_device:
while ( TestCooperativeLevel() != D3DERR_DEVICENOTRESET )
{
do_win_messages();
Sleep(10);
}
release_stuff();
d3d_device_ptr->Reset(&params);
while ( TestCooperativeLevel() != D3D_OK )
{
do_win_messages();
Sleep(10);
}
reload_stuff();
reset_stuff();


release_stuff:
call OnLostDevice for all your interfaces (fonts, sprite object, etc). You don't
have to release them. Release all default memory pool resources: dynamic textures,
dynamic bitmaps, index and vertex buffers you allocate, etc. Note that
LoadMeshFromX with no flags defaults to D3DPOOL_DEFAULT, and Mesh.GetVertexBuffer
returns a copy of the mesh's vertex buffer object, not its address. Both of these
bit me when trying to find all the places I created something in D3DPOOL_DEFAULT.


reload_stuff:
Call OnResetDevice for your interfaces (fonts, sprite object, etc).
Reload / recreate your D3DPOOL_DEFAULT resources: dynamic textures, dynamic
bitmaps, index and vertex buffers you allocate, etc. This is basically a copy
and paste of the code where you do this the first time.




reset_stuff:
Pretty much all of D3D's internal states get wiped on lost device, so you have to
set everything back to the way you want it again. This will vary by title.
I reset everyting that I set between the time I create the D3D device and the
time I start the game itself:
set default material
set flexible vertex format
set projection matrix
set default texture stage states
set gourard shading
turn on mipmaps
set min mag filetrs to anisotropic
set ambient light level
turn on normalizing normals (I do scaling and lighting)
turn on specular
turn on alpha blending




I saw one posting that tested co-op level before calling present, but that would
add an unnecessary check when things are running correctly, i would think.

The basic idea is you wait for "device not reset". You have to process windows
messages while you do so. It has to do with D3D knowing when you get focus back
apparently. The call to Sleep() releases clock cycles to the OS while you wait.
When you get "Device not reset", you release stuff from vidram. Then you call
Reset().

IF YOU STILL HAVE STUFF IN VIDRAM, Reset() WILL FAIL WITH "Invalid Call"!

If Reset() succeeds, you then have to wait for DirectX to come back alive. So you
test cooperative level until you get "D3D_OK". During this time, apparenly windows
will switch the resolution to match your desired resolution, thus the need to wait
a moment. Again, windows messages must be processed while you wait, and you want
to Sleep() to give clock cycles back to the OS. Once you get "D3D_OK", you own
the video card again, and you're pretty much back where you were when you first
created your D3D device, except your managed stuff is still loaded. Call OnReset()
for your interfaces (font, sprite, etc), reload or re-create your non-managed
resources, reset D3D back to the way you want it, and your done! Posted Image

Ok, so you do all this, and it doesn't work, or it works sometimes, but not at
other times. Then what? Enter the dreaded "Purple Screen"! purplescreen(); is
a simple tesing routine that you can insert into your code to determine where
you are creating things in vidram that you're not releasing. In semi-pseudocode:

void purplescreen()
{
int a;
a=0;
do
{
beginscene
clear // clear screen to purple 100,0,50
endscene
result=present
if result == D3DERR_DEVICELOST do_lost_device()
do_win_messages();
if (keypressed(VK_ESCAPE)) a=1;
Sleep(10);
}
while (a != 1);
}


While the purple screen is displayed, you can alt-tab to and from your game, then
hit Esc to continue. Use it to "bracket" where you're using vidram you need to
relase. If you can alt-tab from the purple screen and back, your ok. If you get
"invalid call" when you Reset(), you've loaded something you haven't released.
So you put the purple screen at program start, right after you load everything.
well of course it works there, you used that code to decide what to release!
So add another purple screen later on, like right after you draw your scene and
present it. OK, doesn't work there. Now you know D3D is allocating vidram
somewhere between those two points. Move around your calls to purplescreen
until you find where. Once you find the resource, add it to release_stuff()
and reload_stuff(). Test it again. Eventually you'll find them all, and all of
a sudden it will work!

The info in this post came from about 4 different sources and took me about two
days to find and put together into working code. It took me another two days
to find, release, and reload/recreate everything in my project. In my case it was
finding index and vertex buffers used to draw procedurally height mapped ground
quads.

Hopefully this post will save someone some time in the future.


Some info on SPU's

Posted by , 04 September 2013 - - - - - - · 692 views

Posted Image
Some info on SPUs:

SPU Architecture description (includes bus fetch speeds!).
Nice. Anyone who took computer architecture will probably find it interesting, it's one bad ass little chip!
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.710&rep=rep1&type=pdf


Wikipedia info on the "Cell" processor:
http://en.wikipedia.org/wiki/Cell_(microprocessor)#Synergistic_Processing_Elements_.28SPE.29

SPU instruction set (PS3 implementation):
http://www.ps3devwiki.com/wiki/Synergistic_Processing_Unit_(SPU)

SPU Application Binary Interface Specification (IBM documents):
https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/76CA6C7304210F3987257060006F2C44/$file/SPU_ISA_v1.2_27Jan2007_pub.pdf
https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/02E544E65760B0BF87257060006F8F20/$file/SPU_ABI-Specification_1.9.pdf


top game engines according to moddb.com

Posted by , 04 September 2013 - - - - - - · 459 views

game engine ratings (with links) according to moddb.com

top rated:
http://www.moddb.com/engines/rated

most popular:
http://www.moddb.com/engines/top


Gamedev Tycoon vs crackers

Posted by , 04 September 2013 - - - - - - · 624 views

An interesting article about the game Gamedev Tycoon, and what the development team did as a pre-emptive strike against game crackers.

The sad thing is the part about 97% downloading the crack instead of buying.

http://www.develop-online.net/news/44003/Dev-stings-pirates-with-anti-piracy-bug



anti-crack info

Posted by , 04 September 2013 - - - - - - · 891 views

a combo of my own notes, and info down loaded about protecting games from being cracked.

some of this is stuff i've learned over the years. some is lists of tips posted online. some is actual "how-to" or more precisely, "how they do it" info. some is descriptions of various methods implemented in specific AAA titles.


my apologies to all for the unedited format. the info was requested in a thread, i didn't have time to clean it up first, but did want to share it.


these first 5 items:

key cd
hack resistant code
hack resistant keydisc check - multiple checks - separte code for each check - not just one subroutine which can be hacked. all must be hacked.
hack resistant exe file (crc check, checksum, filelength check)
virtual machine code


is the basic DRM scheme i've evolved over the years.


the following section is highlights of my latest online research.


the next section starting with demo: and full version: is a more detailed description of my drm method, followed by an analysis of its weaknesses and ways to strengthen it.


the next section starting with most cd checks are cracked by using wdasm describes how specific protections are cracked.


the next section is a list of the protections available in PC-GUARD (a typical 3rd party drm solution).


the final section from gammasutra is a description of the copy protection used in Spyro: Year of the Dragon for the PS1. Spyro YOTD didn't get cracked for two months after release.







copy protection

key cd
hack resistant code
hack resistant keydisc check - multiple checks - separte code for each check - not just one subroutine which can be hacked. all must be hacked.
hack resistant exe file (crc check, checksum, filelength check)
virtual machine code
serial number
delayed reaction to copy violation - makes it harder to find check code
generic error message: please contact tech support
use checkcode type procedure names for init var routines - if they hack it, the vars dont get init'ed. dont use checkcode type procedure names like keyCDok() for the checkcode. use something else meaningless or obscure.
dont use meaningful filenames like licence.dat
Add long delays. Don't warn the user right after a violation is made. Wait later, maybe until the next day or two (crackers hate that).

Add short delays. Pause a second or two after a password entry or to your other checking routines to make brute force cracking unfeasible. Simple to do, but rarely done.


Store serial numbers in unlikely places like as a property of a database field. Often heard and read: "..give it a DLL file name and store it in the System directory." Too often heard, don't use it. ;-)

Store serial numbers in several places.

Don't use literal strings that tell the user: "Sorry, but... (whatever)." These are the first things to look for. Build strings dynamically or encrypt them.
encrypted strings for "insert key cd", etc
Don't use validation functions. Every time you validate the user, write your validation code inline with the current process. That just makes more cracking for the cracker and bewares of just NUL'ing out your routine.


Flood the cracker with bogus calls and hard-coded strings. Decoys are fun.

Have fun with Spaghetti-Code simply eats his time and nerves..

No "disabled" features. If your program doesn't save data in "crapware" edition, don't include a "grayed" menu item. No saving means no saving - the code should not be included in the EXE - that's it. Most programming languages offer you a really easy way to maintain several versions of your code by simply doing the following:
{$IFDEF trial}
... no action here ...
{$ELSE}
... advanced functionality for registered user ...
{$ENDIF}

Release several, slightly modified versions.
{$IFDEF Anticrack_Method36}
..protection code #36 comes here..
{$ENDIF}

By doing the an adapted variation of the tip mentioned before, you can easily vary your code and enable/disable it (by defining or undefining the related DEFINE variable) to create slightly different versions of your program executables. This will keep the crackers busy since many of their fellow fans will repeatedly tell them that "crack xy is not working!!!" if they just downloaded the program from somewhere else than the cracker himself did it. Either the software pirates would now be forced to create a number of cracks for each "build", to fill up their server space with a complete setup package of one of your builds along with the crack which works on it or simply to give up on your program.
btw., this is also a cool method to make a special build for your registered users or preventing "registered" code to be compiled into the officially downloadable demo release (which crackers can often "enable" with just a few minutes of works as explained elsewhere on this page).

Update often. Frequent updates mean: frequently changing code, so the typical (simple) crack which is just patching hard-coded byte positions, will possibly already be outdated when published. Also prevent uploading them to public servers, so that you have better control about where your app sits around and people don't find older versions the cracks can still use. Yes, this doesn't prevent pirates from including the version to the crack package, but IF they do so, you can at least contribute to filling up their harddisks.

Create special temporary unlock codes, that work only for a limited amount of time (say 15-30 days). Send this code immediatly upon registration .. then wait a bit (e.g., for the credit charge to be validated). Only then send the unlimited code. That way, the "cracker" will not know that something is wrong and happilly post his code to the warez sites. By the time it spreads, the code will have stopped working. Thus making a fool of the "cracker" amongst his friends for distributing non-working codes. This is a method also handy for beta testers or reviewers.
Use strong encryption. Just XORing is not really strong - use something with an algorithm that isn't easily reverse-engineered, and don't put both encryption and decryption code in your app.

demo: strip out full verion code using "#IFDEF demo" conditional compilation
they cant hack what aint there.
full version:
keycd. multiple checks. separate inline code for each check. IE no keyCDok() routine.
key cd cant be copied. game wont run w/o key cd, unless hacked.
hack resistant exe file (crc check, checksum, filelength check).mutiple checks. separate code for each check. spread code out in program no 2 lines together. prevents code being modified.
encrypted exe. a vm decripts the encrypted exe, runs the decrypted exe, then erases the decrypted exe. prevents them looking at the exe file.
make the entire game one big file:
vm exe
vm code to decrypt, run, then erase the game
the encrypted exe
the encrypted data files.
all appended together. the vm opens the big game file and loads vm code that reads the remaining files and decrypts them, runs the decrypted game, then erases the decrypted game. encrypt with unique key for each registered copy.
they dont get any obvious files to work with. just the one file to decypher. when they look at the beginning of it, its a vm rtm. this is followed by some vm code, and encrypetd game files. they woul d have to translate the vm code and then decrypt the game files to get a look at the exe file
write entire game in vm. do speed critical stuff as c subrotines
so "run main loop" would be a vm opcode implemented as a big c subroutine.
problem: need to check keyCD inside main loop.
ok so checkcode must be in main loop wich is machine code in memory. get a dump, disassemble, and you have assembly source code for the checkcode.
so the checkcode must be hidden. spead out. with mutiple instances. if a check requires 6 lines of code, do each line at a different place in the main loop.
CDcheck should test for both good and bad spots. that way hacking the result to always be bad or good wont work.
what about a mini vm that does the check?
write the check cd routine in vm:
bad sector list is already loaded
keycd data file is already open for reading
seek badsector1-1
read
if error terminate program
seek badsector1
read
if no error terminate program
seek badsector1+1
read
if error terminate program
repeat for badsector2 etc
system id # and registration code. sysid generated from hd, processor etc.
give them registration code that only works with that system id. problem: if system changes, systemid changes, and game no longer works.
give each registered version a serial number. they must neter reg code for that serial number. problem: they can copy the game and pass along the reg #.
problem:
check code cant slow the game down. must be fast and infrequent.
vm ops for cdcheck:
seek some_spot
result = read
test result
abort
so they can always see machine code in memory.
and they can always translate vm code.
so all they have to do is dump the rtm from memory and then use its code to decipher the vm code.
so the vm code must be encrypted. that way all they have is the rtm, and an encrypted data file. but the data file must be decrypted for thr rtm to use it. any decrypt ruotine can be deciphered, whether implemented in c or vm. any routine can be deciphered weither in c or vm. vm is more work to decipher. once they disassemble the rtm, they have the asm source code for the vm opcode parser. from that they can easily write a vm disassembler. wiht the vm disassembler they can trsndlste the vm code back to source code and look for copychecks. once they find the copychecks they hack them by editing the vm code, or by making a compiler and recompiling.
essentially vm implements the program as a machine code that they must figure out (disassmble and reverse engineer the rtm) and then translate to english by hand or write a vm disassembler. then they must edit vm machine code to hack the game or write a vm compiler.
so a vm language translates from english to vm opcodes. a compiler translates english to opcode. a disassembler translates opcode to english.
in the end a game is numbers telling the pc what to do.
a hacker can change those numbers, making the game work without keyCD.
all you can do is makwe it hard. hard to figure out what to change. hard to figure out how to chnage it. lots of work to actually change it.
code spread one line at a time all over the main loop. read result stored in flag for later checking. use read result flag and other junk to set various flags, eventually taking action on one if copy violation. this way they have to trace all the flags. they start by tracing file i/o. from therre they find the reads. but the reads just set flags, so they must trace the flags. eventually something uses a flag to degreade or abort.
most cd checks are cracked by using wdasm to find the promt string to insert the keycd. so the prompt string should be assembled one char at a time, instead of hard coded.
disassembler can find all occurances of any winodws call (IE readfile etc) so it can find cd check by looking for file io routines.
most cracking techniques seem to use dialog box text as the way they find the appropriate code. IE they look for text in the code that they see in the program, such as "Please insert game disc".
idyle phonebook pro 97 had no text for entering registration key, but had error msgbox w/ the only button in the program for crc check error msg. the hacker in the tutorial couldn't easily find the reg code due to lack of strings. a breakpoint on hmemcpy took him to the realtime reg validation code. his patch triggered the crc check code. that triggered the msgbox, which he then traced via a search for BMSG in softice.
another case of looking for program specific text messages (IE "Insert Disk") or windows api calls (mBtn, msgbox, hmemcpy, getdrivetypeA, etc).
code for demo spash screen located by setting breakpoint on windows routine loadbitmapA using softice.
tracing is done using softice and hex editor. softice can search for symbols, hex editor can search for opcodes.
30 day limit traced via windows getlocaltime call.
set breakpoint on getlocaltime. step thru code til nag screen appears. unstep thru code looking for suspicious jumps. flow control is manipulated by editing jmp calls. change jmp on greater to jmp on less than, etc. then run the program and see if it worked. if not, undo the edit and try again. routines are bypaased by inserting returns (ret). jumps are bypassed by nop'ing them out. sometimes conditional jumps are changed to non conditional jumps to hack them.
trace until nagscreens popup. trace the call to the nagscreen. kill the call to the nagscreen. test it. repeat until no more nags.
"[to hack] a registration routine we must breakpoint on [the windows] api ( windows functions) used to read Your name and Your Sn.
They are:
Getwindowtext
GetwindowtextA
Getdlgitemtext
GetdlgitemtextA
Hmemcpy (that's not an api but it's the best)"
the api calls are used to locate reg related message screens. they then play around with conditional jumps that appear above these api calls to disable the reg code.
many apps store reg info in windows registery, which hackers can hack. dont store info in registry.
pcguard:
- Advanced software copy protection.
Protect software from illegal copying from one computer to another.

- Simple and effective protection procedure.
No need for additional programming. Source code editing is not required.

- Application encryption.
Protect software from reverse engineering and analyzing.

- Application password protection.
Protect access to application with password.

- Evaluation (trial) version feature.
Easily create demo version of software with execution, date, fixed date and timer limitations.

- Serial numbers feature.
Mark each copy of your software with unique serial number.

- Flexible machine locking.
Lock software to target computer. Seven locking parameters are available: HD volume ID, Bios ID, OS ID, CPU ID, Network card ID, HD hardware ID and CD/DVD hardware ID.

- Secure distribution.
Securely distribute your software over the Internet or on any distribution media CD/DVD/floppy...

- Secure and simple license management.
Enable licenses by phone, fax or e-mail.

- Advanced protection interface system.
Easily check license status and interact with protection code directly from your application.

- License removal feature.
Allow your client to securely remove program licenses from his computer.

- License transfer feature.
Allow your client to transfer program licenses from one computer to another.

- Limited license feature.
Rent or lease your software by combining available license limitations (number of runs, number of days, fixed date limitation).

- Updates policy feature.
Limit free updates by setting updates policy for protected application.

- Custom features.
Easily enable or disable features (modules) inside your application. 16 features can be passed via standard activation code. Up to 320 additional features can be passed via extended activation codes by using custom counters as sets of features. Feature status can be checked from protected application by using protection interface.

- License extension feature.
Easily update issued license before it expires. Update features, counters, limitations...

- Evaluation period extension feature.
Demo (evaluation) period can be extended after it expires by issuing special activation code.

- Runtime encryption system.
Fragments of code are marked in source code by using special start and end labels. These fragments of code in compiled application are recognized by PC Guard and are additionally encrypted during protection process. Runtime encrypted code always stays encrypted in memory. It is not decrypted during application startup. It's managed by special code each time it should be executed. Once it is executed it's encrypted again.

- Language editor.
You can manage (edit/load/save) more than 70 interface messages for 15 different languages including messages from all interface dialog boxes.

- Custom dialogs feature.
Use your own dialogs instead of default interface dialogs!

- IP Filtering system.
Easily enable access to protected application only from computers with specific IP addresses or from specific sub-domains. You can define up to 30 different IP filters (unique IP addresses or sub-domains). IP filtering can be combined with any protection method.

- Network licensing.
Network protection method is suitable for controlling (limiting) number of workstations simultaneously accessing protected program located on network server. You can combine network protection method with IP filtering feature to additionally lock protected program to target network.

- Machine ID feature.
Securely check the status of locking parameters in order to prevent false requests for new unlocking codes in the case of HD crash, bios upgrade, disk format, virus attack and similar events.

- Easy management of protected program updates.
Auto-unlocking feature is available for protected program updates.

- "Lock program to installation directory" feature.
You can now lock program protected with remote protection method to its installation directory. Once it's unlocked, program can not be started from different directory. This counts for current and all future installations of the same program.

- "Limit number of application instances" feature.
You can now easily control (limit) number of application instances per computer. For applications running under Windows server terminal services number of instances is valid per server and not per workstation. You can thus use this feature to implement network floating licensing in such environment.

- Custom counters feature.
You can now securely manage (change/save) 10 custom (long integer) counters directly from your application by using protection interface.

- Four customizable buttons for activation dialog box.
You can enable/disable four buttons and assign action string for each button. Action string can be a document name, folder name or http link for example. This will allow your client to open your web page, help or license agreement file just by pressing appropriate custom button.

- Advanced overlay management code (AOM)
Advanced overlay management (AOM) is a new, universal approach for managing protection of non-standard applications with internal overlays.

- Unique support for non-standard applications.
Special support for the following compilers/applications is available: ACD FotoAngelo, Active e-book compiler, AL Pictures Slideshow Studio, AutoPlay Media Studio, Macromedia Authorware, Macromedia Director, Macromedia Flash, TrainerSoft, FlashJester - Jugglor, Bink video player, Help and manual, Game editor, Linder Setup Builder, Dark Basic compiler, LabView, Microsoft Camcorder, Multimedia fusion, NeoBook, Mediator, Opus Pro, Photoshop droplet files, PPT to Flash Studio, FreeWrap, Power Builder, Real Basic, Adventure Game Studio, Runtime revolution compiler, SecurePack, Techsmith?s Camtasia, Visual DBase, Brilliant Database SDK, WBTExpress, WinBatch, WinDev, Zinc.

- Activation center (ACEN)
Full featured ASP .NET 2.0 WEB application for online management of clients, programs, orders and licenses with flexible automated activation system. More info...

- Support for third party licensing.
You can fully control third party licensing with AC Generator.

- Support for calculation of activation codes over Internet connection.
Easily integrate calculation of activation codes over Internet with AC Generator WEB.

- Support for calculation of activation codes from your own application.
Easily integrate activation code calculation into your application with AC Generator API.

from gammasutra:
one company used crc checksums of the program in memory to make sure code was not modified. all checksum code was inline (not in a function). they ran multiple checksums starting at different offests and with different intervals (every byte, every 5th byte, etc) over the same piece of memory. they embedded bytes in the code to make the checksums add up to some predetermined value. they had mutiple implementations of the crc code, each unique, so it was harder to find.
Simply doing an XOR of as much of YOTD's code as possible before burning it to the CD means that this technique will not work. It also makes it difficult to match up data in memory with its source on the disk. We worked under the assumption that code can't be modified if it can't be found.

Second, we made it as difficult as possible to debug. If you've ever had to debug code that behaves differently when you trace through it, you know how much of a pain debugging can be. We used trace traps to make the code behave differently if breakpoints had been placed. The checksum helped with this, as any software breakpoints used would alter the checksum.
In YOTD we had four layers, including the copy protection.

The copy protection stopped the game very early.
we designed the game to break in ways that weren't immediately obvious. Most of the protection is "off-camera," affecting levels other than the one currently being played. In YOTD the object of the game is to collect eggs and gems, which are then used to open later parts of the game. The protection removed eggs and gems, so that the player could not make progress. We tried to make the game unplayable for any length of time, while at the same time making it difficult to determine exactly where things had gone wrong. If errors accumulated slowly until the game broke, the cracker would not notice such behavior so easily.

Other, more obvious protection was done less frequently. Callbacks were corrupted, which made the game crash in odd ways. The European version changed languages randomly. Some of these actions break the game and others are just an annoyance to the player, but if the game is difficult or frustrating to play because of the failed crack, this can be more effective than breaking completely.
By making the game behave in as many odd ways as possible, we hoped to cause a lot of confusion. The pirates wouldn't know if the crack didn't work, whether they had just failed to apply the crack correctly, or if the disk had failed to burn correctly. The people who didn't play a lot of the game wouldn't notice that anything was wrong and claim that the crack worked. This happens more than you would think. A lot of people pirate more out of habit than anything else, booting up the game to have a look before moving on quickly. All of this would help to delay a complete crack from being made, because no one would be sure that it was required.
Any version of the game with protection included was very difficult to debug, as any software breakpoints would trigger the protection. Beyond a certain point, hardware breakpoints were turned off by the copy protection.
exe's are compressed on disk w/ proprietary compression algo. hacker must hack the compression before they can hack the exe. then they must recompress the cracked software.




==================================================================================================


a comment from my original posting of this info in my old journal:




leeor_net said:

>> But I will reiterate that the first number of suggestions are effectively useless for the above stated reasons (competent crackers will get around any of these 'measures').


yes, straight forward implementations of things like check sum etc will get bypassed swiftly. as with much of crack protection, its more about obfustification, than the protection algo used. even a 100% secure hardware lock can be bypassed in the code if its implementation is not hidden.


the idea is to slow them down. you can't stop them. with unlimited resources and time, they will crack anything. you just have to slow them down enough to keep them out until you release a new version. so in the spirit of slowing them down, you want to present to them all the usual hoops to jump through. after all, they'll be expecting them (things like checksums), so why disappoint them? but be clever about it, one checksum out in the open where they expect it, maybe a second easy to find one, and then one or two (or more) hidden ones. and then do likewise for all the "usual suspects" in the way of expected protections. then once they get past all that de-regeur stuff, then they get into the REAL protection methods.


much of it has to do with the hassle to benefit ratio for the cracker. on the hassle side, you have the difficulty of actually craccking the game. a long and tedious cracck can turn from fun to challenging to frustrating as ttime goes on. on the benefit side, you have the glory of posting the crack, which is a function of game size, price, quality, and popularity. bigger, more expensive, higher quality, popular games = more bragging rights for cracking it. so the cost of implementing protection must be weighed against the chances of getting cracked, based on the game's, popularity, price, quality, and size.


the one thing you don't want to do (and i did it once), is underestimate the protection required, and get cracked. when that happens, all you can do is release a major new version that's so vastly superior to the current version that people will buy it instead of just playing the current version for free. and if the game is a mature title, coming up with a vastly superior new version can be difficult, as the software product has already matured, and most new versions are now incremental feature improvements coupled with new content. imagine if tiger woods got cracked. it would take EA some time to come up with a vastly superior new version to compete with the cracked current version.



Sony Computer Entertainment Europe Research & Development Division Pitfalls of Object Oriented Programming

Posted by , 04 September 2013 - - - - - - · 446 views

an interesting read.

as can be seen from the article, the traditional c++/oo way of organizing code can be inefficient, depending on implementation.

in the article, they refactor into a more component type architecture (arrays of component types vs object components contained in the object instances).

http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf