The auction

I decided to "start over" with just a small piece of the system so that I could practice getting through all phases a little more quickly. I took just the auction piece and wrote some user scenarios and then began to design and develop it. It was much easier thinking about the project on this smaller scope. It's not totally done, but I have enough pieces of it working that I can buy and sell things on it.

 
 

I think now I will start over again with the larger project now having some experience making it all the way through and experiencing the value of having a more thorough design.

 
 

Creating a game requires a lot of creativity, but what keeps hanging me up is that I am thinking that I will apply that creativity in the development phase instead of the design phase. Something I have to realize is that almost all of the creativity should be applied in the design and planning phases while the development is really more just construction.

 
 

This has been tough for me because I like to be creative as I build. Growing up I loved playing with blocks and Lego's because I would create what ever it was as I built it. I might have had a general idea of where I was headed but definitely no specifics. For example I might have had the idea to build a car or a space ship our of Lego's. So I would grab some wheels and longer Lego's and attach them. Then I would look for an engine of some sort and some doors. It was easy to trade pieces out as I went and to see the functionality of my project as I went. But I would have no idea about color or size of wheels or really even how big the car would be in the end. Sometimes I would find cool Lego's I could add to give the car wings or arms and I would add them for fun.

 
 

This "Create as you Build" mentality has not been working for me with this project. I would like to test out all the different "cool parts" as I built them and then decide if I wanted to keep them, adjust them, or remove them. What I am learning is that the create part of the project is in the planning, which doesn't seem to be as fun for me. But I am going to proceed that way and not write any code (except maybe to test ideas) until the game can be played thoroughly on paper.

More road blocks and learnings

I've decided to start documenting my learning's as I go more regularly, so hopefully I actually do learn from them and won't make the same mistakes over. I went through a second attempt pretty quickly. I looked over my requirements docs and thought they looked good enough, so I started designing the database again. I started using Visio as I said I would, but then it started looking extremely like the database designer diagrams I built before, so thought why have that extra step. So I did it all in the SQL Server database diagram. It went really quick because I was able to use most of the previously designed database.

I then quickly created the data access layer by drag/dropping the tables onto a dataset. It created all of the data table adapters for me quite quickly. With that my intention was work on the business logic layer by creating a class 'on top' of each table adapter, but I soon found the job quite daunting. With the great code generators Visual Studio has with the dataset designer and class designer I was hoping I could find a way to generate the business logic layer some, like I did with the data access layer. Searching the web I didn't find much, but I did come across a document in the Jumping Into ASP.NET series that outlined the "Application Planning and Designer". I thought that maybe with the road blocks I kept hitting I would look at this stage again so I read it. It makes reference to using User Scenarios, which I have done some of, but after reading this section I realized I hadn't done nearly enough. So I have begun creating these and have recognized several other major road blocks and hurdles that I would have hit on the path I was headed. There were complete other systems within the system I am attempting to build that I hadn't considered completely enough.

So now my current objective is to complete the User Scenarios so there is a scenario for every interaction the user may encounter with the system. I don't know if this is over doing it or not, but I think it will help to ensure every aspect has been thought about. I have started a list of User Scenarios I am going to write and already there are about 20. In the article I read the author had written just a couple examples of a fairly simple application, but mentioned that it would probably take about 20. So if that simple application could have used 20, then I'm assuming this one I am working on could take many more.

Up to now ...

Starting out in this project I had the idea of creating an economy simulation type game that I could use as an experiment for understanding how an economy works and how outside influences might affect it. My goal was to start out with a governmental type entity that provided a source for all products to be bought and sold so there would never be a shortage of anything and there would always be somewhere to put surplus, though the prices would be severely skewed to create a large window for competing prices. But then eventually the central government would not be needed any more so the economy would be self supporting. At least that is the overall goal.

I have had this idea for half a year now, but didn't really get started until about 1 month ago. I started out writing, as detailed as I could, the game design. I included what the overall goal of the game is, what the goal of the players would be, and how they could achieve those goals. I then transferred those designs into system requirements including what the system would have to 'know', meaning the data it would have to keep track of, and also what it would have to do, or calculations it would have to make and functionality it would have to enable the players to do.

I inherently knew the type of architecture the system would have, because of the types of systems I have been working on and the architecture most web systems take on. It would have a database backend with a web front end. The specific technologies would be SQL Server and ASP.NET because that’s what I know and have resources for. So I began designing a database for the entire system. This took awhile and seems to be overly complex.

I tried finding tools to help create an ER diagram like how I did it in school with rectangles representing entities, diamonds representing relationships, and circles representing attributes. Of course there's more detail within an ER diagram, but those were the basics I was looking for. I couldn't find anything really good for free. I have MS Visio and it says it has an ER diagram template, but it's not like I learned in school. So I ended up creating my own stencil within Visio and designed the database. It didn't take too long before it was so big and there were so many connections that it looked like spaghetti with square and diamond shaped meat balls. A lot of the time I spent on it was trying to keep it clean and readable.

Finally I had something I could translate into a database and so I began building a database diagram in SQL Server 2005. A nice feature of this is that I can create the tables and relationships between the tables all within the diagram.

By the time I finished the diagram I decided that it might be better to only implement part of the system so I wrote out an 'Iteration 1' system that simply captured overall pieces of the whole system. There wasn't much detail in this 'Iteration 1'. So even though I had a 'complete' database, I wasn't going to implement all of it into the front end.

It's worth saying here as well that another intention was to learn new parts of SQL Server and ASP.NET that I haven't used before so that it would be an even better educational experience. So part of the purpose of 'Iteration 1' was to get something fully functioning quicker so that I could have experience with the 'new stuff'. To list a few of the things I wanted to use: AJAX, SQL Server Triggers, Wizard controls, and Strongly typed datasets.

I have read some about keeping the logic layer separate from the other parts of the system. With a lot of SQL stored procedure experience I thought it would be easiest for me to have a schema in the database that just contains the stored procedures responsible for the business logic and then have a data access layer utilizing strongly typed datasets and data table adapters to communicate with the data. So it sounds kind of reverse from what I was reading about, but I thought this would be easiest for me.

As I progressed I soon realized that I hadn't spent enough time in the previous steps. I found gaps in the game design, which lead to larger gaps in the system requirements, and even larger in the database design. I even found gaps in the data design due to it just not being thorough enough. The requirement was their but it was only vaguely satisfied. It had been far to easy and appealing for me to move on to the next step with out having a thorough previous step. But at the same time I found myself staring at a step (say the ER diagram) and not sure what else to do with it so I would move on. It wouldn't be until later that I would discover a gap or conflict and then need to go back and partially redesign. This of course meant that I may have needed to implement those changes through out the other steps implemented.

So where I am now is I almost have a complete 'Iteration 1', but have discovered too many design gaps and conflicts to have an elegant finish. I have already made some 'hacks' to be able to move forward but progress is slowing down and the 'wins' from having a well thought out design are disappearing.

So now I am thinking of starting over utilizing what I have learned. I have thought about the process I will take and even though I don't know if it is the best, this is what I am going to do. I will review the game design and system requirements. I feel that these should be complete enough by now. I will work on the project in iterations, but not as severely as the first time. I will implement the full database design, but cut out the 'gold plating' aspects such as AJAX and look/feel stuff, but the full interaction with the data will be there. I will use MS Visio to create a 'Microsoft' entity relationship diagram. Even though I don't feel it is a true ER diagram it is the stencil that Microsoft has included and since I am using exclusive Microsoft tools, it might make the most sense in the end. Besides, does it really matter if a relationship is represented by a diamond or another 'entity'. A relationship will have to be modeled within a table anyway right, so might as well start out that way.

I will then create the actual database which should be very simple since it will already be modeled as such. And I know that Visio can actually create a SQL server directly from and Entity Relation diagram.

I will change some of my naming conventions. Initially I had several objects named the same but within different schemas. For example I had two Product tables with different field names, but they had different purposes. One was for product definitions while the other was for actual products that a player actually owned. So one was actually Param.Product while the other was Data.Product. Even though they are in different schemas it still proved to be a little confusing in other places like the typed datasets that didn't really have an element for schemas. It also looked a little weird in the database diagram.

I also used too simple of field names for key fields. For example in the Param.Product table it had a 'Name' which was its primary key. Then in other tables referencing it as a foreign key there was a Product_Name which referenced it. Through out the system it got confusing when to use the 'simple' version (Name) and when to use the more fully qualified version. So I am going to change this so that field names are more fully qualified throughout.

To follow many of the tutorials I have read about I am going to put the actual database logic in a layer outside of the database on the other side of the access layer. I know how to do it within stored procedures, but I haven't experienced it the other way, so before I can say that stored procedures are easier I will do it both ways and then be able to make a better say. This is a learning experience for me so I might as well do it differently (and more like the industry standard).