Showing posts with label BASIC. Show all posts
Showing posts with label BASIC. Show all posts

Thursday, 29 December 2016

Announcement : My Book On Kindle!

You can pre-order my Kindle e-book today for delivery the 1st of January 2017!



For all those times you wonder about not knowing quite how to approach programming, or if you've lost your confidence with overly technical tomes trying to teach you, try my personal, one to one approach!

The text takes on the same format as the books I learned to program from in the 1980's, it helps you understand the basics never throwing into fits of rage or despair, I am right there with you to guide you.

This is the first book in what I hope to make a series, it takes you through basic variables, numbers, math, text processing, into the basics of lists and then object orientated programming, ending up with error handling and file processing.

I think the Python programming, despite a few quirks, is an excellent starting point for any beginner today, it lends itself to introducing programming across multiple platforms oh so very quickly, but one can still find jobs out there specifically requiring Python skills!

Pre-Order today!  And I'll see you inside!



Monday, 28 July 2014

Imperial Conquest - Atari ST - My Version Pt 1

Some of you out there will know of my background as a war-gamer, yes I started out playing online games - and games with other people - as grand table top strategy games...

I've played many, from way back on the Atari ST with my favourite, and first, strategy games (like Carrier Command and then Imperial Conquest).

I particularly likes Imperial Conquest, it was written in STOS (a dialect of basic) and featured on the cover disk of STFormat.  And I wrote off with £5 of my pocket money to buy a real copy - which came back as a diskette - no box, it was a proper indy game!

The idea of Imperial Conquest was you had a world view, well a Europe high view, which showed the cities and armies and fleets as just dots... You could then click and see a smaller snap shot of the land... If you got it clicked on the wrong spot, you just had to go back up a level and go back down; there was no scrolling...

You held cities, and from them each turn you got income, a turn being a month, and then you paid from your income for armies/units you controlled, and you moved these army counters around to take other cities.

Very basic, but very addictive...

So, my next personal project is going to be an Imperial Conquest clone, this is to a) get me back into coding and playing war games, and b) to teach me some more platform portable 2D OpenGl Code.


 The first thing I did was trace an outline of Europe, using Red for Land, Blue for sea and orange for rivers.  These will be my terrain types for now... And I wrote a C# program to parse this image into a raw map, the map can be any size, I've tried everything from 640x480 to 4096x3096.

This is the top level, as per the original game, and you click on it and it'll zoom the view in...


This is where I've been adding configuration, I'm not sure what size to make this tactical level view, so it renders the terrain square as just a solid colour type for the moment... I've already plans for texturing this and adding coast lines, but I'm working on pure mechanics for now... Too many games rush to add visuals before making it work solidly....

So, I added an XML configuration:


Which lets me set the number of squares to render on this tactical view, and how big these squares are... I then played about





Before settling on quite a large view, to match what was given in the original game:


Now, this level of XML control is also extended into most all parts of the system, so this is more a war game visual representer engine than a game at present... But it works how I want it to.

The next Item I needed were some counters I could throw into the screen... So I went with an icon for Infantry, one for cavalry, and an engineer to help bridge those rivers:


I'm going to be keeping this very simple, and perhaps even may publish the code as a tutorial into using SDL and OpenGL.  Its also aiming to be cross platform, so you will see this on Linux soon.

Thursday, 3 April 2014

Code Line Numbers

I had a programmer sat with me the other day, he seems a good one too, though I've not seen his actual code.  And he surprised me by peering at my development environment and saying...

"How can you program without line numbers on?"

He was serious, we were exchanging information to ensure I wrote code to meet his coding standards... So why not program with line numbers... Well, I could be annoying and say, I don't write BASIC, so I don't need line numbers... I also don't count K-Locs as a form of reward as to how busy I've been, nor use it as a measure of how productive I am... So really I have to ask myself the opposite, "Why don't you program with line numbers on Xel?"

And the simple answer for me is experience.  Maybe you're different, and you like line numbers, if so "This is not the article you are looking for, move along... Move along"... But to answer for myself, it is simply because I'm human, and the human mind likes to see patterns, it likes to see things and tries it's hardest to impose some semblance of meaning into them.  And for me, if I turn line numbers on then I expect 5 to follow 4, and 4 to have followed 3, and 2 to have come before 3 but after 1... It's an order, and in modern code it is an incorrect order because we should be writing, if not object orientated, then at least functional code.

Functions can be called in any order, objects can be instantiated and used differently by different users, your code itself might do one sequence one way today but a different sequence tomorrow.  The functions themselves still do the same single job with the same input, as per their definition, but code as a whole is no longer linear.

So over time my personal experience has told me to group my code into a simple, but not formal - until this blog post - order, which is "Constructors at the top", then the functions defined "in order of frequency of use", so if you have an update function called all the time in a class, put it at the top, so its easy to spot after your constructors.  Especially in a language like C++ where your constructors can be very brief - or should be very brief, if they're not go rear Scott Meters & Bjarne Stroustrop on the topic!

And then functions are laid out in order of use, least used or single call functions are at the bottom.  I've just come to this pattern, its quite hard to even define it here in words, I suppose I should give code examples, but I'll leave this for another day and come full circle to answer the question "How can you program without line numbers on?"

"Code/Function use is not linear, don't give any indicates to your mind that it is, and if you're going to argue about the contents of one function, your function is too long, break it down into sub-functions which will fit onto the screen as a whole and so you don't need line numbers you can see the whole function in a single pass of the eye".