From NEAT Portal Wiki
Jump to: navigation, search
(Accessing the Code)
 
(42 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
== What you Need ==
 
== What you Need ==
 
* Mercurial ("hg") version control system. [http://tortoisehg.bitbucket.org/ http://tortoisehg.bitbucket.org/]
 
* Mercurial ("hg") version control system. [http://tortoisehg.bitbucket.org/ http://tortoisehg.bitbucket.org/]
* Flash Compiler (ie, FlexBuilder 4.5) [http://www.adobe.com/products/flash-builder.html http://www.adobe.com/products/flash-builder.html] or FlashDevelop [http://www.flashdevelop.org/wikidocs/index.php?title=Main_Page http://www.flashdevelop.org/wikidocs/index.php?title=Main_Page]
+
* Flash Compiler [http://www.adobe.com/products/flash-builder.html FlexBuilder 4.5] or FlashDevelop [http://www.flashdevelop.org/wikidocs/index.php?title=Main_Page FlashDeveloper] or [http://fpdownload.adobe.com/pub/flex/sdk/builds/flex3/flex_sdk_3.6.0.16995.zip the Free SDK] and [http://download.macromedia.com/pub/flex/sdk/datavisualization_sdk3.3.zip Data Visualization libraries]
 
* ''Future:'' Zinc [http://www.multidmedia.com/software/zinc/download/ http://www.multidmedia.com/software/zinc/download/]
 
* ''Future:'' Zinc [http://www.multidmedia.com/software/zinc/download/ http://www.multidmedia.com/software/zinc/download/]
  
 
== Accessing the Code ==
 
== Accessing the Code ==
# Send a PM (private message) to StayDawg  ... '''Unless you are a kick ass developer or know you way around PHP and the Paypal API the source is closed for now'''
+
# Send a PM (private message) to StrayDawg
 
# "Pull" the source to your computer or online hg respository
 
# "Pull" the source to your computer or online hg respository
 
#* hg clone ''repositoryURL''
 
#* hg clone ''repositoryURL''

Latest revision as of 11:41, 25 April 2012

What you Need

Accessing the Code

  1. Send a PM (private message) to StrayDawg
  2. "Pull" the source to your computer or online hg respository
    • hg clone repositoryURL
  3. Do an "update" if it's been a while since the last clone:
    • hg update
  4. Make changes
  5. Test your code
  6. Document your code why it does it, how it does it, and how you have tested it, and how you know it won't break any existing functionality.
  7. Create a "diff" from your "working set"
    • hg diff >my_descriptive_patch.patch
  8. Email patch to one of the main developers.

Code Structure

|-- media --/  mp3 files for alerts, warnings, etc
|
|-- fonts --/   portable non-system fonts
|
|-- html-templates/ ???
|
|-- libs --/ libraries needed to compile
|
|-+-+- src --/
   |    |-- AutoEvony.mxml -- what you modify to enhance the "command" window
   |    \-- config.xml   -- You might need to modify this for a new project
   |
   |-- images --/
   |
   |-- com --/      communication routines and template response objects
   |
   |-+ autoevony --/
      |
      |-- common --/  utility classes and constants
      |
      |-- event --/
      |
      |-- gui --/
      |
      |-- net --/
      |
      |-- player --/
      |
      |-- scripts --/
      |   \---   CityState.as -- what you modify to enhance scripting
      |
      |-- management --/
          \---   CityManager.as   -- What you modify to enhance the goal-operations

Event Model

ActionScript is much like C. Even if you don't know C, but know some programming, you can probably get started easily enough. Adobe has copious amounts of resources on the language itself.

What might be confusing is the event model. All the code that runs in a flash window is single-threaded. This means only one thing can happen at once. There are no interrupts. If you want to "do something" that requires a response from the server, you sometimes have to write three functions. The first is the one that gets called when you click a button or type in a command. This method might dispatch a server request. After your code sends the dispatch, it typically "returns", meaning no code is running. The second function is the response handler to the server request. This is executed when the server has received your request and responded to it. Usually, your handler will be called right away, but sometimes other events (such as a timer or a previously dispatched response) will execute first. When your response handler is called, you might need to make a second request to the server, meaning a third function to handle that response.

If you want to do a lot of processing, you might have to break up your code into timeslices. Here, you dispatch an event called a timer which will execute your response handler at some point in the future, say 1 second. Your event handler will do the same thing, do some work, and return. In this way, you can simulate multiple "threads" of operation; this is pretty much how each city is handled. (But it's in fact more complicated than that.)