Advice required on Excel games

[Bartek]

Since MS made Visual Studio a free download, it seems almost a waste of time to bother with VBA as a game development platform anymore...
VBA being non-compiled really puts a damper on game animation.

Well, you seem to miss a point here. Of course, Excel is not a perfect game development platform - it was never supposed to be - but this is a very reason to develop a game on it - it's a kind of "less is more" philosophy mixed with the desire to make something a bit crazy.

Developing a game under serious constrains imposed by the platform, like in case of MS Excel, may be very beneficial to the quality of game mechanics and to the success of a project. This looks like a paradox, but makes sense: probably only a tiny fraction of "indie" (independent) game projects fail because their developers could not cope with limitation of the engine. It seems that the cast majority of projects fail because of the exactly opposed reason - the desire to find better and better engine, endless changes associated with it and so on.

Of course, there are some other factors involved, like making a perfectly "boss secure" game - no employer will disable the Excel Application in his office

 

[clut]

Another factor here is that I work 46 hours a week + an hour driving time each day, I have a family, including a 3 year old son and various hobbies I like to engage in. This all leads to having very little time to devote to any one single project.

For me, Excel is a perfect games development platform because I don't need to write code to pull all sorts of data around in a game, or to perform calculations on multiple items as Excel can do these things with simple worksheet functions like vlookup.

This allows me to spend more time designing the game mechanics (as Bartek mentioned) and less time bug hunting.

Another factor that Blood mentioned was the animation. For me graphics can kill a game and many developers these days think that fancy graphics makes a game good. I disagree and believe sound mechanics, good re-playability, interesting premise and intuative design make for a good game.

Yes Excel may be very limiting, and VBA not the optimal langauge for generating fancy graphics, but they suit my needs just fine.

 

[Aaron Blood]

I don't think I'm missing any points here...

I should remind (or inform) some here that I maintain probably the largest collection of Excel-based games on the internet.

I like doing games in Excel...

I've completed a few pretty good ones in Excel. After you do it for a bit you'll get the urge to migrate. One of the main reasons is lack of interest in Excel-based games. Hard to find beta testers and so forth.

Most offices that would allow the installation of MS Office could be easily persuaded to also install the free Visual Studio (tell em it's a more powerful version of VBA, and you want to use it to compile custom function DLL's).

But if you want to play with Excel stick to what it's good for... (not driving games!) Excel makes a good platform for: board games, card games, dice games, puzzles, typing tutor, strategy and/or RPG's that are turn-based are also doable. Although, if the strategy game has any depth at all, developing AI that's fun to play against will be the most difficult task.

 

[PaddyD]

"... I maintain probably the largest collection of Excel-based games on the internet."

For those who do need reminding / informing:

http://www.xl-logic.com

 

[MorganO]

Aaron,

Your posts on Visual Studio intrigue me. I have never programmed in pure VB so I am wondering if the transition from VBA to VB is very difficult. I picked up VBA through a lot of dabbling (self taught myself pure pure BASIC back in the late 70's) so I wondering if you think it would be a fairly easy transition to make from VBA to VB. Although I have enjoyed seeing how far I can take Excel VBA, I am certainly interested in moving to a more powerful programming platform at some point.

I do agree, Excel is certainly more suited to certain types of games than others. For me, Excel Rocks started as a much simpler 'WingDings' font game and kind of just spiraled almost out of control. I ran into many roadblocks that I could not overcome; primarily speed - VBA just isn't capable of. With VB, that is not as much of a problem, and I could have probably nearly duplicated Boulderdash perfectly in VB.

But, I really do love the 'Wow - you can do that in Excel?' reaction I get when I show people an impressive Excel Game.

Owen

 

[Cbrine]

Owen,
I made the transition to VB 6.0 and VB.net just fine. If you have dabbled in ADO, class building, referencing the excel object from another program and API's. I would say you should be able to move to vb 6.0 without any major issues. You will have a few things that are done different in the setup of the IDE, but the actual coding will be pretty close. The VB 6.0 coding you do can still be used in VB.net, but VB.net has implemented better ways to do the same thing. I ended up taking a course for it, which helped me get a grounding in the basics. I think it might be easier to learn VB.net without and knowledge of VB 6.0, since you then have no preconceptions.

HTH
Cal

PS-I won't speak about about VB 6.0's distribution packages setup...cause that's a bit of a nightmare, although 3rd packages are available that make this easier. The VB.net setup packages were implemented in a much better way IMO, but they are still complex.

 

[Bartek]

I should remind (or inform) some here that I maintain probably the largest collection of Excel-based games on the internet

Well, my Excel Games Library list over 130 games, being probably the biggest one, but size is not an argument here

I once wrote a complete shareware RPG game with C++ (in the ancient era of unfriendly DOS) so I am not afraid of hard-core programming. The reason to use Excel is based on it being the very unique and interesting engine. In that sense, Excel is not inferior to typical programming platform, is only different. There is a funny and well-written article in Gamasutra exploring this approach:

Microsoft Excel: Revolutionary 3D Game Engine?

One of the main reasons is lack of interest in Excel-based games.

Well, it depends. When I wrote my first game it became so popular it interfered with the operation of the entire department of important governmental body (people were playing it instead of working on important IT project)

I think that people will not be very impressed in playing Excel implementation of known popular games, like, let’s say, Tetris. They may like it, play once or twice and that’s all. But making a unique Excel game with high load of "excelness" factor... that’s another story.

 

[Aaron Blood]

Well, my Excel Games Library list over 130 games, being probably the biggest one, but size is not an argument here

OK... well I didn't associate "Bartek" with dzikosoft... If I recall, you started your collection by emailing me and asking if it would be OK to contact all the game authors on my website for permssion to include them on yours. I haven't bothered to reciprocate in that practice.

 

[clut]

But making a unique Excel game with high load of "excelness" factor... that’s another story.

This is something I've wanted to do for a while...

the basic idea is have a simple worksheet with some figures and graphs on. It all looks pretty boring and business like. Your task is to change some data. When you try to change things, Excel starts fighting back... Graphs go weird, your changes aren't accepted, it moves the cursor around for you and gives you insulting message boxes... that sort of thing. This then develops into a kind of You vs Excel type game, where you must conquer Excel and bring it back under control.

I haven't nailed the finer mechanics yet. Half of me thinks this would be boring as hell, and half of me thinks it'd be really cool. I haven't decided yet.

 

[Aaron Blood]

I do agree, Excel is certainly more suited to certain types of games than others. For me, Excel Rocks started as a much simpler 'WingDings' font game and kind of just spiraled almost out of control. I ran into many roadblocks that I could not overcome; primarily speed - VBA just isn't capable of. With VB, that is not as much of a problem, and I could have probably nearly duplicated Boulderdash perfectly in VB.

Visual Studio is very interesting in the sense that it allows people with different programming backgrounds to essentially all work with the same object models, libraries, and compiler. You can write an app in VS using VB.net and then compile it with the same C# compiler and you end up getting close to (if not identical) performance in the compiled app.

Graphically speaking, you can access and program the GDI (graphics development interface) or work with DirectX. It's up to you.

There's a learning curve in migrating to vb.net, from VBA. Although if you're well familiar with VBA, you'll find the leap can occur easily inside of a week or two. Some of the things you learn in getting into vb.net can then translate into another transition down the road to C#. Personally, I just like the structure and layout of vb code better than C# and I'm getting to equal performance with vb so I'm not that inclined to move yet.

You will find that you are generally programming at much lower levels than VBA (or even VB6 for that matter!) and it will take you awhile to develop your own libraries of components to work with. But once you have those in your toolbox it translates to rapid development. For instance, you'll have to learn about hit-testing and how to go about building your own "retained mode graphics" systems.

You'll spend a lot of time contemplating what sort of classes you need and building exactly the types of controls you want to play with. As opposed to VBA or even VB6 where you are confined in your choices.

My top goal for the moment in vb.net is to develop graphic object controls that live in the GDI environment with characteristics similar to the drawing controls you get to use in Excel. I want the user to be able to right-click a GDI drawing object at runtime and see a property window that can be manipulated.

That's where I'm at for now...